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Abstract 

This  standard  specifies  an  Open  Systems  Interconnection  application  layer  service  definition  and  protocol  specification  for  Information 
Retrieval.  The  Information  Retrieval  protocol  allows  an  application  on  one  computer  to  query  the  database  of  another  computer.  The 
protocol  specifies  the  procedures  and  structures  for  the  intersystem  submission  of  a  search  request  (including  the  syntax  of  the  query), 
request  for  the  transmission  of  database  records  located  by  a  search,  the  responses  to  the  requests,  access  control,  and  resource  control. 


FOREWORD 


This  forward  is  not  a  formal  part  of  the  standard. 

ANSI  Z39. 50-1992,  American  National  Standard 
Information  Retrieval  Application  Service  Definition 
and  Protocol  Specification/or  Open  Systems  Intercon- 
nection, is  a  revision  of  ANSI  Z39.50-1988.  The 
1988  and  1992  versions  of  Z39.50  are  referred  to  as 
versions  1  and  2  respectively. 

Version  1  was  prepared  by  Committee  D,  "Comp- 
uter-to-Computer  Protocols",  of  NISO,  the  National 
Information  Standards  Organization.  Committee  D 
was  organized  to  develop  OSI  application  layer 
protocols  for  library  applications,  including  m 
information  retrieval  protocol.  The  committee  was 
disbanded  after  Z39.50  version  1  was  approved.  In 
1989,  the  Z39.50  Maintenance  Agency  was  formed, 
administered  at  the  Library  of  Congress.  Version  2 
has  been  prepared  by  the  Maintenance  Agency,  to 
incorporate  enhancements  described  in  detail  below. 

In  1990  the  Z39.50  Implementors  Group  (ZIG) 
was  established.  Members  include  manufacturers, 
vendors,  consultants,  information  providers,  and 
universities,  who  wish  to  access  or  provide  access  to, 
various  types  of  information,  including  bibliographic, 
full  text,  financial,  public  utility,  chemical,  and  news. 
Thus,  although  the  protocol  was  originally  proposed 
(in  1984)  for  use  with  bibliographic  applications, 
interest  in  Z39.50  as  an  information  retrieval  protocol 
is  no  longer  limited  to  use  with  bibliographic  infor- 
mation. 

Z39.50  version  2  represents  a  consensus  of  the 
ZIG,  which  has  in  effect  acted  in  an  advisory  capaci- 
ty to  the  maintenance  agency,  in  the  effort  to  develop 
version  2.  ZIG  Membership  has  been  open  to  all 
interested  parties. 

Information  Retrieval  Protocol 

The  protocol  specifies  formats  and  procedures 
governing  the  exchange  of  messages  between  a 
requesting  computer  (the  "origin")  and  a  responding 
computer  (the  "target")  to  enable  the  origin  to  1) 
request  that  the  target  search  a  database  and  identify 
records  which  meet  specified  criteria,  and  2)  request 
transmission  of,  and  receive,  some  or  all  of  the 
identified  records. 

The  origin  may  initiate  requests  on  behalf  of  a 
user  who  wishes  to  search  a  database  located  on  the 
target  system.  The  protocol  addresses  communica- 
tion between   corresponding   information  retrieval 


applications  on  the  origin  and  target  systems;  it  does 
not  address  interaction  between  the  origin  computer 
and  user. 

Base  Operations 

The  Information  Retrieval  protocol  provides  the 
following  basic  capabilities.  The  origin  may  submit  a 
Search  request  which  includes  a  query,  and  parame- 
ters which  determine  whether  or  not  records  resulting 
from  the  search  are  to  be  returned  as  part  of  tine 
response.  The  target  responds  with  a  count  of  records 
identified  and  possibly  some  or  all  of  the  records. 
The  origin  may  then  submit  a  Present  request, 
requesting  transmission  of  selected  records.  The 
origin  assumes  that  records  selected  by  the  search 
request  form  an  ordered  set  (the  "result  set")  which 
may  be  referenced  by  sequential  position  within  the 
set.  Record  order  is  determined  by  the  target.  The 
origin  may  request  (for  example)  records  one  through 
four,  and  follow  with  a  request  for  records  four 
through  eight,  and  then  records  two  through  three, 
etc.  The  origin  may  submit  as  many  such  Present 
requests  as  desired,  and  may  men  submit  another 
Search  request. 

Optional  capabilities  include  the  following: 

-  The  origin  may  specify  element  set  names 
indicating  data  elements  which  should  be 
transmitted  in  cases  where  the  origin  does  not 
wish  to  receive  complete  database  records. 
For  example,  the  origin  might  specify  "If  5  or 
less  records  are  identified,  transmit  'full' 
records;  if  more  than  5  records  are  found, 
transmit  'brief  records".  (In  this  example,  the 
meanings  of  'full'  and  'brief  are  target 
specific.) 

-  The  origin  may  specify  a  preferred-record- 
syntax  for  response  records.  For  example,  it 
might  identify  a  bibliographic  format  such  as 
USMARC. 

-  The  origin  may  name  a  result  set  for  subse- 
quent reference. 

-  The  origin  may  delete  a  named  result  set. 

-  The  target  may  impose  access  control  restric- 
tions on  the  origin,  by  demanding  authentica- 
tion before  processing  a  request. 

-  The  target  may  provide  resource  control  by 
sending  an  unsolicited  or  solicited  status 
report.  This  might  occur  during  processing  of 
an  operation,  in  which  case  the  target  may 


suspend  processing  and  allow  the  origin  to 
decide  whether  the  operation  should  continue. 

Query  Formulation 

This  standard  mandates  support  of  the  Type-l" 
query  as  a  common  format  for  the  intersystem  trans- 
mission of  a  search  query.  The  "Type-l"  query, 
fully  specified  in  this  standard,  expresses  a  search 
query  by  individual  search  terms  (or  phrases)  with  a 
set  of  attributes  for  each.  Attributes  may  specify,  for 
example,  type  of  term  (subject,  name,  etc.),  whether 
it  is  truncated,  and  its  structure.  The  target  is  respon- 
sible for  mapping  these  attributes  to  the  logical  design 
of  the  database. 

Several  terms  may  be  combined  in  »  Type-l 
query,  linked  by  boolean  operators.  Terms  and 
operators  are  expressed  in  Reverse  Polish  Notation. 

Attribute  Sets 

The  attributes  associated  with  a  search  term  belong 
to  a  particular  attribute  set,  whose  definition  assigns 
integer  values  to  various  attributes.  The  definition  is 
assigned  a  unique  and  globally  recognized  "attribute- 
set-id",  an  OSI  Object  Identifier,  which  is  included 
within  the  query.  , 

The  process  of  assigning  an  OSI  object  identifier 
is  called  "registration".  Appendix  C  (which  is  part  of 
the  standard)  defines  and  registers  one  attribute-set- 
id,  "bib-1",  which  specifies  various  attributes  that  are 
useful  for  bibliographic  queries.  There  is  a  mecha- 
nism to  register  additional  attribute  sets.  Just  as  the 
bib-1  attribute  set  was  developed  by  the  bibliographic 
community,  it  is  intended  that  attribute  sets  will  be 
developed  and  registered  as  needed  by  other  commu- 
nities (for  example,  a  chemical  attribute  set  by 
chemists). 

Response  Records 

The  protocol  provides  for  the  transfer  of  database 
records  identified  by  a  Search  or  Present  request. 
The  standard  distinguishes  two  types  of  records, 
database  and  diagnostic  records,  which  can  occur  in 
response  messages  from  the  target. 

Appendix  E  (which  is  part  of  this  standard) 
registers  object  identifiers  for  various  MARC  for- 
mats, including  USMARC,  UKMARC,  Norway 
MARC  and  CANMARC;  these  object  identifiers 
accompany  database  record  returned  by  the  target. 
There  is  a  provision  for  registration  of  additional 
record  formats,  including  non-bibliographic  formats. 

Diagnostic  records  are  similarly  accompanied  by 
an  object  identifier  which  identifies  their  format. 
Appendix  D  (which  is  part  of  this  standard)  defines 


and  registers  one  diagnostic  record  format,  abib-l", 
which  includes  various  diagnostic  codes  that  are 
useful  for  bibliographic  applications.  Additional 
diagnostic  record  formats  may  be  registered. 

Changes  in  Yemon  2 

Z39.50  version  2  incorporates  major  enhance- 
ments to  version  1,  in  two  categories: 

-  changes  necessary  for  alignment  with  ISO 
10162/10163,  the  Search  and  Retrieve  (SR) 
Service  Definition  and  Protocol  Specification; 
and 

-  incorporation  of  features  deemed  necessary  by 
implementors,  to  provide  sufficient  functional- 
ity so  that  implementation  can  be  economically 
justified. 

Alignment  with  SR 

When  SR  was  approved  in  1991,  incompatibilities 
between  Z39.50  version  1  and  SR  remained: 

-  SR  Search  and  Present  requests  include  pa- 
rameters (related  to  record  composition  and 
syntax)  not  included  in  Z39.S0  version  1. 
Specifically:  (1)  the  search  request  in  SR  has 
both  small-set-  and  medium-set-  element-set- 
name  parameters.  Z39.50  version  1  has  only 
a  single,  or  global,  element-set-name  parame- 
ter. (2)  SR  includes  the  parameter  Preferred- 
record-syntax,  and  Z39.50  version  1  does  not. 

-  The  SR  Delete  service  allows  the  origin  to 
specify  a  list  of  result  sets  to  be  deleted. 
Z39.S0  version  1  allows  deletion  of  a  single 
specified  result  set  only. 

-  SR  uses  ASN.l  ("Abstract  Syntax  Notation 
one")  to  define  the  abstract  syntax  of  its 
protocol  data  units,  and  specifies  ASN,  1  Basic 
Encoding  Rules  for  transfer  syntax.  Z39.50 
Version  1,  finalized  before  ASN.l  was  stable, 
developed  a  non-standard  abstract  syntax 
notation  and  corresponding  transfer  syntax, 
which  in  version  2  have  been  abandoned  in 
favor  of  ASN.l. 

-  A  major  limitation  of  Z39.50  version  1  is  the 
lack  of  flexibility  to  reference  objects,  includ- 
ing attribute-sets,  diagnostic-sets,  and  record 
formats,  which  SR  references  through  OSI 
object  identifiers. 

Z39»5©-Specifk  Features 

The  above  differences  are  resolved  in  Z39.50 
version  2.  There  will  still  be  differences  with  SR, 
however.  Z39.50  includes  two  services  not  yet  in 
SR:  access  control  and  resource  control.  Some  U.S. 


information  providers  cannot  use  Z39.50  if  it  does 
not  include  an  access  control  service.  Both  services 
have  been  carefully  incorporated  so  that  an  SR  and 
Z39.50  version  2  origin/target  pair  may  interwork 
transparently  (i.e.  the  SR  implementation  would  not 
be  aware  that  its  partner  is  a  Z39.50  rather  than  SR 
implementation). 

In  general,  implementors  who  plan  to  build 
Z39.50-specific  features  into  their  implementations, 
for  use  when  interworking  with  a  Z39.50  partner, 
would  suppress  these  features  when  interworking  with 
an  SR  partner.  Thus,  lack  of  these  features  in  SR 
will  not  inhibit  interoperability,  although  it  might 
limit  potential  functionality.  For  example,  informa- 
tion that  an  SR  origin  can  receive  from  a  Z39.50 
•target  might  be  limited  because  the  origin  cannot 
respond  to  an  access  control  request.  (The  same 
would  be  true  of  a  Z39.50  origin  which  does  not 
support  access  control  —  it  is  an  optional  service). 
The  limitation  would  not  owe  to  an  incompatibility 
between  origin  and  target  implementations,  but 
rather,  because  the  target  requires  authentication  and 
the  origin  cannot  provide  it. 

Version  2  includes  changes  to  the  Resource 
Control  facility.  The  origin  will  be  able  to  request  a , 
resource  control  action  or  cancel  an  operation.  These 
changes  have  been  expressed  as  requirements  by  the 
ZIG. 

Version  2  specifies  five  query  types.  Types  0,1, 
and  2  are  identical  to  the  three  query  types  specified 
in  SR.  The  "Type-0"  query  is  designated  "private", 
allowing  two  systems  to  use  a  private,  mutually 
agreed  upon  query  format.  Type-l"  is  described 
above.  "Type-2"  is  as  specified  by  ISO  8777. 
Z39.50  specifies  two  additional  query  types:  Type- 
100"  is  as  specified  by  ANSI  Z39.58,  and  atype-10P 
is  for  proximity  searching.  The  latter  is' specified  in 
appendix  G.  Proximity  searching  is  a  feature  that 
implementors  recommended  be  incorporated  into  this 
version. 


experimental  and  implementation-specific  objects. 
The  Z39.50  Maintenance  Agency  will  act  as  registra- 
tion authority  for  Z39.50  objects. 

Future  Serrlces 

The  generality  of  the  protocol  is  intended  to  allow 
accommodation  of  new  services  as  they  are  required. 
Some  services  being  considered  are: 

-  Explain:  to  allow  an  origin  to  obtain  details  of 
the  target  implementation,  including  databases 
available  for  searching,  data  elements  in 
records  of  a  specified  database,  element  sets 
supported,  elements  within  in  a  specified 
element  set,  attribute  sets  supported,  attributes 
supported  within  a  supported  attribute  set, 
diagnostic  sets,  and  record  syntaxes. 

-  Define  Element  Set:  to  allow  an  origin  to 
define  and  name  a  set  of  elements  to  compose 
a  retrieval  record. 

Scan:  to  allow  an  origin  to  obtain  a  list  of 
access  point  values  from  a  database  index 
(subject  terms,  names,  titles,  etc.),  preceding 
and  following  a  specified  access  value. 
Object  Access:  To  allow  an  origin  to  perform 
operations  including  create,  delete,  sort, 
export,  activate,  and  permit,  on  various  ob- 
jects, including  result  sets  and  queries, 
segmentation:  to  allow  a  target  to  return 
multiple  responses  to  a  single  present  request. 


Object  Identifiers 

Z39.50  registers  all  information  objects  that  are 
registered  in  SR:  application  context,  abstract  syntax, 
attribute  set,  diagnostic  set,  and  record  syntax  defini- 
tions. In  addition,  Z39.50  attribute  set  and  diagnostic 
set  definitions  contains  additional  attribute  and 
diagnostic  values  which  are  "U.S.  specific''. 

Z39.50  registers  two  additional  object  identifier 
classes:  resource  report  format  (for  resource  control, 
which  is  not  yet  in  SR),  and  transfer  syntax.  The 
latter  accommodates  non-bibliographic  databases. 
Z39.50  also  provides  a  mechanism  for  registration  of 
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1.  Introduction 

This  is  one  of  a  set  of  standards  produced  to 
facilitate  the  interconnection  of  computer  systems.  It 
is  positioned  with  respect  to  other  related  standards 
by  the  Open  Systems  Interconnection  (OSI)  basic 
reference  model  (ISO  7498).  The  aim  of  Open 
Systems  Interconnection  is  to  allow  the  interconnec- 
tion of  computer  systems,  with  a  minimum  of  techni- 
cal agreement  outside  the  interconnection  standards. 

This  standard  defines  a  protocol  within  the  appli- 
cation layer  of  the  reference  model,  and  is  concerned 
in  particular  with  the  retrieval  of  information  stored 
in  machine  readable  databases. 

1.1  Scope  and  Field  of  Application 

This  standard  describes  the  Information  Retrieval 
application  service  (section  3)  and  specifies  the 
Information  Retrieval  application  protocol  (section  4), 
for  Open  Systems  Interconnection. 

The  Information  Retrieval  application  service  is 
described  in  terms  of  services  which  provide  capabili- 
ties within  an  application.  The  description  neither 
specifies  nor  constrains  the  implementation  within  a 
computer  system.  The  purpose  of  the  service  descrip- 
tion is  to  define  the  functions  that  the  protocol  must 
support. 

The  protocol  specification  includes  the  definition 
of  the  protocol  control  information,  the  rules  for 
exchanging  this  information,  and  the  conformance 
requirements  to  be  met  by  implementation  of  this 
protocol. 

This  standard  is  intended  particularly  for  use  by 
systems  supporting  information  retrieval  services  for 
organization  such  as  libraries,  information  utilities, 
and  union  catalogue  centers.  It  addresses  connection- 
oriented,  program-to-program  communication  utiliz- 
ing telecommunications.  It  does  not  address  the 
interchange  of  information  with  terminals  or  via  other 
physical  media. 

O  Model 

The  objective  of  this  standard  is  to  facilitate  the 
open  interconnection  of  database  users  with  database 
providers.  It  is  necessary  to  distinguish  between  the 
set  of  OSI  standards  and  the  hardware  and  software 
implementation  of  a  system  using  the  protocols 
specified  in  these  standards.  The  ways  hi  which 
databases  are  implemented  differ  considerably; 
different  systems  have  different  styles  for  describing 
the  storage  of  data  and  the  means  by  which  it  can  be 
accessed.  A  common,  abstract  model  is  therefore 
used  in  describing  databases,  to  which  an  individual 


system  can  map  its  implementation.  This  enables 
different  systems  to  communicate  in  standard,  mutu- 
ally understandable  terms. 

The  term  "database8  as  used  in  this  standard  refers 
to  a  collection  of  one  or  more  files,  each  with  a 
unique  name.  A  group  of  files  within  a  database  may 
also  have  a  name  and  be  accessed  as  a  single  data- 
base. The  unit  of  information  for  retrieval  from  a 
database  is  a  record.  All  of  the  records  within  a  given 
file  have  a  common  structure,  contain  a  common  set 
of  data  elements  and  a  common  set  of  access  points. 
An  access  point  is  a  unique  or  non-unique  key  which 
can  be  specified  either  singly  or  in  combination  with 
other  access  points  in  a  search  for  records.  An 
access  point  may  be  equivalent  to  a  data  element,  be 
derived  from  a  data  element,  or  the  combination  of 
all  or  part  of  two  or  more  data  elements. 

A  search  query  may  be  applied  to  a  database, 
specifying  values  to  be  matched  against  the  access 
points  of  the  database.  The  subset  of  records  formed 
by  applying  the  search  query  is  termed  the  result  set. 
A  result  set  may  itself  be  referenced  in  a  subsequent 
search  query  statement  and  manipulated  to  form  a 
new  result  set. 

For  generality,  it  is  assumed  that  query  processing 
does  not  necessarily  require  physical  access  to  re- 
cords; a  result  set  is  thus  assumed  to  be  the  identifi- 
cation of  (e.g.  pointers  to)  records,  as  opposed  to  the 
actual  set  of  records,  selected  by  a  query.  (It  is  not 
assumed  mat  the  database  records  are  locked. 
Methods  of  concurrency  control,  which  would 
prevent  modification  or  deletion  of  result  set  records, 
are  not  addressed  by  this  standard.)  A  result  set  may 
be  used  as  a  selection  mechanism  for  the  transfer  of 
records  between  systems;  the  result  set  itself  is 
considered  to  be  a  purely  local  data  structure  and  is 
not  transferred  (that  is,  records  are  transferred,  but 
not  the  local  pointers  to  the  records). 

A  generic  search  query  statement  is  composed  of 
g  database  name  followed  by  a  query  statement.  The 
Type-1  query  statement  defined  in  this  standard 
consists  of  either  a  single  access  point  clause,  or 
several  access  point  clauses  linked  by  logical  opera- 
tors. For  example: 

"In  the  database  which  is  named  'Books'  find  all 
of  the  records  for  which  the  access  point  'title 
word'  contains  the  value  'evangeline'  AND  the 
access  point  'author'  contains  the  value  'long- 
fellow'0. 

Following  the  processing  of  a  search,  the  set  of 
items  with  the  specified  properties  (the  result  set)  is 
made  available  by  the  target  system,  to  the  origin 
system,  for  subsequent  retrieval  requests.    For  the 


purpose  of  retrieving  records,  the  logical  structure  of 
a  result  set  is  that  of  a  named,  ordered  list  of  triples 
consisting  of  (a)  an  ordinal  number  corresponding  to 
the  position  of  the  triple  in  the  list,  (b)  a  database 
name,  and  (c)  a  unique  record  identifier  (of  local 
significance  only)  within  the  database  named  in  (b). 
A  result  set  item  is  referenced  by  its  position  within 
the  result  set,  that  is,  by  (a). 
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for  the  Association  Control  Service  Element  1987. 

ISO  8777  -Documentation  -  Commands  for  Interac- 
tive Text  Searching 

ISO  8822  -  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Connection  Oriented 
Presentation  Service  Definition  1988. 

ISO  8824  -  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Specification  of  Ab- 
stract Syntax  Notation  One  (ASN.l)  1987. 

ISO  8825  -  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Specification  of  Basic 
Encoding  Rules  for  Abstract  Syntax  Notation  One 
(ASN.l)  1987. 

ISO  9545  -  Information  processing  systems  -  Open 
Systems  Interconnection  -Application  Layer  Struc- 
ture 1989. 

ISO  10163  -  Documentation  -  Search  and  Retrieve 
Protocol  Specification  1991. 

2„   Definitions 

For  terms  which  are  formally  defined  in  other 
standards,  the  formal  definition  is  given,  italicized, 
and  the  standard  is  listed  in  parentheses.  In  those 


cases,  descriptions  and/or  alternate  definitions  (in- 
dented) are  sometimes  provided.  All  of  the  defini- 
tions below  including  the  alternate  definitions  apply 
only  to  the  Information  Retrieval  application  service 
and  protocol,  and  only  within  the  context  of  this 
standard. 

APDU  -  See  Application  Protocol  Data  Unit 

Application  Association  —  A  cooperative  relation- 
ship between  two  application-entity-invocations  for 
the  purpose  of  communication  of  information  and 
coordination  of  their  joint  operation.  This  relation- 
ship is  formed  by  the  exchange  of  application-proto- 
col-control-information using  the  Presentation-Ser- 
vice.   (ISO  9545) 

For  the  Information  Retrieval  service  and  proto- 
col, an  application  association  is  analogous  to  an 
individual  communication  session  between  a 
database  user  and  a  database  provider.  Each  asso- 
ciation consists  of  an  origin  application  and  a 
target  application,  and  these  roles  may  not  be 
reversed  within  an  association. 

Application  Entity  —  The  aspects  of  an  application- 
process  pertinent  to  OSI.  (ISO  7498) 

Application  Protocol  -  The  rules  governing  the 
format  and  exchange  of  information  between  an 
origin  and  target  application. 

Application  Protocol  Control  Information  -  The 
information  conveyed  by  application  protocol  data 
units. 

Application  Protocol  Data  Unit  -  A  unit  of  data 
specified  in  an  application-protocol  and  consisting  of 
application-protocol-information  and  possibly  appli- 
cation-user-data. (ISO  7498) 

A  unit  of  data  passed  between  an  origin  and  a 

target. 

Application  Service  User  -  That  portion  of  an 
application  which  makes  requests  upon  the  open 
systems  environment.  (The  concept  of  service-user 
is  employed  to  facilitate  the  specification  of  protocol 
procedures  and  is  not  analogous  to  the  database  user.) 

ASN.l  -  Abstract  Syntax  Notation  One. 

Conditionally  Confirmed  Service  -  A  confirmed 
service  in  which  the  response  might  under  certain 
conditions  not  occur. 


Confirmed  Service  -  A  distinct  part  of  the  total  IR- 
service  which  results  in  an  explicit  confirmation  from 
the  service-provider  to  the  initiating  service-user. 
(ISO  TR  8509) 

A  service  which  consists  of  a  request  followed  by 
a  response.  A  confirmed  service  may  be  initiated 
by  the  origin,  in  which  case  it  consists  of  a  re- 
quest by  the  origin  followed  by  a  response  from 
the  target;  or  it  may  be  initiated  by  the  target,  in 
which  case  it  consists  of  a  request  by  the  target 
followed  by  a  response  from  the  origin. 

Connection  Oriented  Communication  -  Communica- 
tion in  which  the  communication  path  is  explicitly 
established  for  an  association,  maintained  throughout 
the  association,  and  explicitly  terminated. 

Database  Provider  -  The  application  which  provides 
access  to  a  database  local  to  that  application. 

Database  User  -  The  application  which  accesses  a 
remote  database. 

JR  —  Information  Retrieval 

Origin  Application  -  The  application  that  initiates  an 
association  and  is  the  source  of  requests  during  the 
association.  The  database  user. 

Name  —  A  linguistic  construct,  expressed  in  some 
language,  which  corresponds  to  an  object.  A  name 
denotes  (i.e.  identifies)  the  object  to  which  it  is 
bound. 

Non  Confirmed  Service  -  A  distinct  part  of  the  total 
IR-service  which  does  not  result  in  an  explicit  confir- 
mation from  the  service-provider  to  the  initiating 
service-user.  (ISO  TR  8509) 

A  service  which  consists  of  a  request  only  (not 
followed  by  a  response).  It  may  be  initiated  by 
the  origin  or  the  target. 

QSI  -  Open  Systems  Interconnection. 

Primitive  -An  abstract,  implementation-independent 
representation  of  an  interaction  between  the  service- 
user  and  the  service-provider.  (ISO  TR  8509) 

Result  set  —  An  ordered  list  of  triples  consisting  of 
(a)  an  ordinal  number  corresponding  to  the  position 
of  the  triple  in  the  list,  (b)  a  database  name,  and  (c) 
a  unique  record  identifier  (of  local  significance  only) 


within  the  database  named  in  (b).  A  result  set  is 
formed  by  applying  a  search  query. 

RPN-  Reverse  Polish  Notation 

Service  provider  —  An  abstract  of  the  totality  of 
those  entities  which  provide  a  service  to  peer  service- 
users.  (ISO  TR  8509) 

(Note:  the  concept  of  service-provider  is  employed 
to  facilitate  the  specification  of  protocol  proce- 
dures. It  is  not  analogous  to  the  database  provid- 
er, and  it  does  not  refer  to  providers  of  telecom- 
munication services.) 

Target  Application  -  The  application  that  accepts  an 
association  and  is  the  sink  for  requests  during  the 
association.   The  database  provider. 

Primitive  Name  -  A  kind  of  name,  the  internal 
structure  of  which  is  not  required  to  be  understood  or 
have  significance  to  users  of  the  name. 

3,  Information  Retrieval  Service 

This  section  defines  the  Information  Retrieval 
service,  which  is  supported  by  the  Information 
Retrieval  protocol. 

3.1  General  characteristics  of  the 
Information  Retrieval  Service 
The  service  definition  describes  an  activity  be- 
tween two  applications  on  different  computers:  an 
initiating  application,  the  origin,  and  a  responding 
application,  the  target.  The  target  is  associated  with 
one  or  more  databases.  Communication  between 
origin  and  target  is  via  an  application  association.  An 
association  is  explicitly  established  by  the  origin  and 
may  be  explicitly  terminated  by  either  origin  or 
target,  or  implicitly  terminated  by  a  communication 
failure  or  other  external  event. 

The  roles  of  origin  and  target  may  not  be  reversed 
within  an  association.  An  association  cannot  be 
restarted,  thus  no  status  information  is  retained  once 
an  association  is  released. 

The  complete  application  service  is  composed  of 
the  association  control  service  element,  which  pro- 
vides association  management,  and  one  or  more 
specific  application  services,  such  as  the  Information 
Retrieval  application  service.  There  are  three  distinct 
phases  during  the  life  of  an  application  association: 
establishment,  information  transfer,  and  termination. 
The  association  control  service  element  provides  all 
of  the  services  required  during  the  establishment  and 


termination  phases,  including  the  selection  of  aa 
application  context  specifying,  among  other  tilings, 
the  set  of  service  elements  which  are  valid  during  the 
information  transfer  phase.  Section  4.2. 1.2  specifies 
those  services  for  association  control  which  are 
assumed  by  the  Information  Retrieval  service. 

3.2  Facilities  of  the  Information  Retrieval 

Semce 

There  are  seven  facilities  defined  by  this  standard. 
Each  of  the  Initialization,  Search,  Present,  Result-set- 
delete,  and  Access  Control  facilities  consists  of  a 
single  service.  The  Accounting/  Resource  Control 
facility  consists  of  three  services.  The  Termination 
facility  consist  of  two  services. 

(1)  Initialization  Facility  Init  Service:  Init 
request  by  the  origin  followed  by  an  Init 
response  from  the  target.  The  Init  service  is 
a  confirmed  service  initiated  by  the  origin. 

(2)  Search  Facility  Search  Service:  Search 
request  by  the  origin  followed  by  a  Search 
response  from  the  target.  The  Search  service 
is  a  confirmed  service  initiated  by  the  origin. 

(3)  Retrieval  Facility  Present  Service:  Present 
request  by  origin  followed  by  a  Present  re- 
sponse from  the  target.  The  Present  service  is 
a  confirmed  service  initiated  by  the  origin. 

(4)  Result-set-delete  Facility  Delete  Service: 
Delete  request  by  the  origin  followed  by  a 
Delete  response  from  the  target.  The  Delete 
service  is  a  confirmed  service  initiated  by  the 
origin. 

Note:  Between  the  Init,  Search,  Present, 
or  Delete  request  and  its  respective  re- 
sponse, there  may  occur  one  or  more  of 
the  following:  Access-control  request/- 
response  sequence  initiated  by  the  target, 
Trigger-resource-control  request  by  the 
origin,  and  Resource-control  request  (and 
possibly  response)  initiated  by  the  target. 

(5)  Access  Control  Facility  Access-control  ser- 
vice: Access-control  request  by  the  target, 
following  an  Init,  Search,  Present,  Delete,  or 
Resource-report  request  by  the  origin  and 
followed  by  an  Access-control  response  from 
the  origin.  The  Access-Control  service  is  a 
confirmed  service  initiated  by  the  target. 

(6)  Accounting/Resource  Control  Facility  The 
Accounting/  Resource  Control  facility  consists 
of  three  services:  the  Resource-control  ser- 
vice, the  Trigger-resource-control  service,  and 
the  Resource-report  service. 


-  Resource-control  Service:  Resource- 
control  request  by  the  target,  following  an 
Init,  Search,  Present,  or  Delete  request  by 
the  origin  and  followed  (possibly)  by  g 
Resource-control  response  from  die  ori- 
gin. The  Resource-control  service  is  a 
conditionally  confirmed  service,  initiated 
by  the  target. 

-  Trigger-resource-control  Service:  Trigger- 
Resource-control  request  by  the  origin, 
following  an  Init,  Search,  Present,  or 
Delete  request  by  the  origin.  The  Trigger- 
resource-control  Service  is  a  non-con- 
firmed service  initiated  by  the  origin. 

-  Resource-report  Service:  Resource-report 
request  by  the  origin,  following  an  Init, 
Search,  Present,  Delete  or  Resource- 
report  response  from  the  target.  The 
Resource-report  service  is  a  confirmed 
service,  initiated  by  the  origin. 

Note:  Between  the  Resource-report  request 
and  its  response,  there  may  occur  one  or  more 
Access-control  request/response  sequences. 
(7)  Termination  Facility  The  Termination  Facil- 
ity allows  an  origin  or  target  system  to  initiate 
abrupt  termination  of  the  association,  or  an 
origin  system  to  initiate  graceful  termination. 

-  IR-abort  Service:  IR-abort  request  by 
either  the  origin  or  the  target.  The  IR- 
abort  Service  is  a  non-confirmed  service 
initiated  by  either  the  origin  or  target. 

-  IR-Release  Service:  IR-release  request  by 
the  origin  followed  by  an  IR-release  re- 
sponse by  the  target.  The  IR-Release 
Service  is  a  confirmed  service  initiated  by 
the  origin. 

The  IR-abort  and  IR-release  services  map 
directly  onto  the  A-ABORT  and  A-RELEASE 
services  (respectively)  of  the  association 
control  service  element. 

3.2.1  Initialization  Facility 
3.2.1.1  Init  Service 

The  Init  service  allows  an  origin  to  propose 
values  for  initialization  parameters.  The  target 
system  may  propose  alternative  values  for  some  of 
the  parameters.  If  so,  the  origin  must  either  accept 
the  alternative  values  proposed  by  the  target  or  else 
terminate  communication. 

3.2.1.1.1  Id/authentication  The  origin  and  target 
agree,  outside  the  scope  of  the  standard,  whether  or 
not  this  parameter  is  to  be  supplied  by  the  origin,  and 
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Table  1:  Parameters  of  the  lnit  Service 


if  so,  what  the  value  is.  This  value  is  used  by  the 
target  to  determine  if  the  origin  is  authorized  to  enter 
into  communication  with  the  target. 

3.2.1.1.2  Options  The  lnit  request  specifies  either 
"will  use"  or  "will  not  use",  and  the  lnit  response 
specifies  "will  support"  or  "will  not  support"  for  the 
following  capabilities: 

1.  search 

2.  present 

3.  delete 

4.  resource-report 

5.  trigger-resource-control 

If  the  target  specifies  "will  support"  for  a  particu- 
lar capability,  then  the  origin  may  assume  that  the 
service  will  be  available  and  may  use" the  service 
during  the  association,  even  if  the  origin  had  speci- 
fied "will  not  use"  for  that  service. 

In  addition,  the  lnit  request  specifies  either  "will 
support"  or  "will  not  support",  and  the  lnit  response 
specifies  "will  use"  or  "will  not  use"  for  each  of  the 
following  capabilities: 

1.  resource-control 

2.  access-control 

If  die  request  specifies  "will  not  support"  for  a 
given  capability,  and  the  response  specifies  "will  use" 
for  that  capability,  then  the  value  of  Result  must  be 
"reject". 

Note:  the  above  two  lists  of  capabilities  are  subject 
to  expansion  in  future  versions  of  this  protocol. 
search   -   The   origin   specifies    'will   use"    for 
"search"  if  it  intends  to  submit  Search  requests. 


The  target  indicates  that  it  is  willing  (or  unwilling) 
to  accept  and  respond  to  Search  requests  by 
specifying  "will  support"  (or  "will  not  support") 
for  "search8. 

present  -  The  origin  specifies  "will  use"  for 
"present"  if  it  intends  to  submit  Present  requests. 
The  target  indicates  that  it  is  willing  (or  unwilling) 
to  accept  and  respond  to  Present  requests  by 
specifying  "will  support"  (or  "will  not  support") 
for  "present  . 

delete  -  The  origin  specifies  "will  use"  for  "de- 
lete" if  it  intends  to  submit  Delete  requests.  The 
target  indicates  that  it  is  willing  (or  unwilling)  to 
•ccept  and  respond  to  Delete  requests  by  specify- 
ing "will  support"  (or  "will  not  support")  for 
"delete". 

Resource-report  -  The  origin  specifies  "will  use" 
for  "resource-report"  if  it  intends  to  submit  Re- 
source-report requests.  The  target  indicates  that 
it  is  willing  (or  unwilling)  to  accept  and  respond 
to  Resource-report  requests  by  specifying  "will 
support"  (or  "will  not  support")  for  "Resource- 
report". 

Note:  The  target  indication  that  it  is  willing  to 
respond  to  Resource-report  requests  does  not 
imply  mat  it  will  include  a  resource  report  in 
the  response. 
Trigper-resource-control  -  The  origin  specifies 
"will  use"  for  "trigger-resource-control"  if  it 
intends  to  submit  Trigger-resource-control  requests 
(if  so,  the  origin  must  also  indicate  that  it  is 
prepared  to  receive  and  respond  to  a  Resource- 
control  request  from  the  target,  by  specifying  "will 
support"  for  "resource-control").  The  target 
indicates  that  it  is  willing  (or  unwilling)  to  accept 
Trigger-resource-control  requests  by  specifying 
"will  support"  (or  "will  not  support")  for  "trigger- 
resource-control  " . 
Notes: 

(1)  The  target  may  indicate  unwillingness  to 
accept  Trigger-resource-control  requests 
even  if  it  specifies  "will  use"  for 
"resource-control " . 

(2)  An  indication  by  the  target  of  willingness 
to  accept  Trigger-resource-control 
requests  does  not  imply  that  the  target  will 
take  any  action  as  a  result  of  a  Trigger- 
resource-control  request. 

resource-control  -  The  origin  indicates  that  it  is 
prepared  to  receive  and  respond  to  a  Resource- 
control  request  from  the  target,  by  specifying  "will 
support"  for  "resource-control".  Conversely,  the 
origin  indicates  that  it  is  not  prepared  to  receive  a 


Resource-control  request  by  specifying  "will  not 
support".  In  the  latter  case,  if  the  target  cannot 
suppress  sending  a  Resource-control  request,  it 
should  reject  the  connection  by  setting  Result  to 
"reject",  specifying  "will  use8  for  "resource- 
contror,  and  (optionally)  supplying  a  text  message 
in  the  User-information-field. 
access-control  -  Likewise,  the  origin  indicates 
whether  or  not  it  is  prepared  to  receive  *nd  re- 
spond to  an  Access-control  request  from  the 
target,  by  specifying  "will  support0  or  "will  not 
support"  for  "access-control". 

Security  is  invoked  at  different  levels.  In 
addition  to  user  authentication  at  the  outset  of  an 
association,  security  might  be  invoked  to  control 
access  to  a  particular  database,  record,  result-set, 
or  use  of  a  command.  It  might  be  used  to  deter- 
mine whether  an  origin  is  authorized  to  request  a 
resource  report. 

If  the  origin  is  not  capable  of  receiving  an 
Access-control  request,  and  if  security  require- 
ments on  the  target  system  mandate  that  security 
(other  than  that  which  might  be  provided  by  the 
parameter  Id/authentication)  be  invoked  at  the 
outset  of  an  association,  then  the  target  should 
reject  the  association  by  setting  the  parameter 
Result  to  "reject",  and  specifying  "will  use"  for 
"access-control".  However,  if  the  target  invokes 
security,  but  not  at  the  association  level,  then  the 
target  may  choose  to  accept  the  connection.  In 
that  case,  if  the  target  subsequently  receives  a 
command  that  would  precipitate  an  Access-con- 
trol request,  the  target  agrees  to  suppress  the 
request  and  respond  to  the  command  with  an  error 
status  indicating  that  a  security  challenge  was 
required  but  could  not  be  issued. 

3.2.1.1.3  Preferred-message-size  and  Maximum- 
record-size  The  Init  request  contains  Preferred- 
message-size  and  Maximum-record-size,  specified  in 
bytes.  Maximum-record-size  must  be  greater  than  or 
equal  to  preferred-message-size.  The  Init  response 
contains  both  the  Preferred-message-size  and  Maxi- 
mum-Record-size  that  the  target  is  going  to  use. 

The  target  has  the  option  of  responding  with 
values  different  from  those  requested  by  the  origin 
(however,  Preferred-message-size  must  be  less  than 
or  equal  to  Maximum-record-size),  in  which  case,  the 
origin  may  abort  the  connection  if  those  values  are 
not  acceptable.  The  usage  of  these  parameters  is 
specified  in  section  3.3. 


3.2.1.1.4  Result  The  target  indicates  whether  or  not 
it  accepts  the  association  by  specifying  a  value  of 
"accept''  or  "reject"  respectively  in  the  parameter 
Result.  If  "reject"  is  indicated,  toe  origin  is  expected 
to  terminate  communication. 

3.2.1.1.1  User-information-field  This  field  may  be 
used  by  either  the  origin  or  target  for  additional 
information,  not  specified  by  this  standard. 

3.2.1.1.6  Reference-id  See  section  3.4. 

3X2  Search  Facility 

The  Search  facility  enables  an  origin  system  to 
query  databases  at  a  target  system,  Mid  to  receive 
information  about  the  results  of  toe  query. 

3.2.2.1  Search  Service 

The  Search  service  allows  an  origin  to  send  a 
query  to  a  target.  The  basic  query  concept  is:  "from 
toe  specified  set  of  items,  identify  those  with  the 
properties  indicated. "  The  set  of  items  identified  is 
called  toe  "result  set",  and  is  maintained  by  toe  target 
for  subsequent  retrieval  requests.  However,  depend- 
ing on  the  parameters  of  toe  search,  one  or  more 
items  identified  by  toe  result  set  may  be  immediately 
returned  as  part  of  toe  search  response.  The  result 
set  is  an  ordered  set;  items  identified  by  entries  in  toe 
result  set  are  referenced  by  toe  position  of  toe  entry 
within  the  result  set,  beginning  with  one  (1). 

3.2.2.1.1  Query-type  and  Query  The  parameter 
Query-type  identifies  toe  syntax  of  toe  query.  As 
noted  above,  toe  basic  query  concept  is  "from  toe 
specified  set  of  items,  identify  those  with  toe  proper- 
ties indicated."  The  "specified  set  of  items"  is  a 
collection  of  one  or  more  databases,  specified  by  toe 
parameter  database-names.  The  "properties  indicat- 
ed" are  specified  by  toe  parameter  Query. 
Five  types  are  defined: 

-  tvpe-0  may  be  used  only  when  toe  origin  and 
target  have  an  a  priori  agreement  outside  of 
toe  standard; 

-  tvoe-l  is  toe  Reverse  Polish  Notation  (RPN) 
query  specified  in  section  3.2.2.1.1.1; 

-  tvne-2  is  toe  IS08777  type  query,  specified  in 
ISO  8777; 

-  tvpe-100  is  toe  Z39.58  type  query,  specified 
in  ANSI  Z39.58;  and 

-  tvpe-101  is  toe  proximity  query,  specified  in 
appendix  G. 
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Table  2:  Parameters  of  the  Search  Service 


3.2.2.1.1.1  RPN  Query  This  section  specifies 
procedures  when  Query-type  is  1,  'RPN-query'.  The 
RPN  query  has  the  following  structure: 

RPN-query  ::=      argument  | 

argument +  argument  +  operator 
argument     ::=       operand  |  RPN-query 
operand       ::=       attribute-set  +  term  | 

Result-set-id 
operator       ::=       AND  |  OR  |  AND-NOT 
Where  ::=       means  "is  defined  as", 
I  means   "or", 


+         means  "followed  by",  and  +  has 
precedence  over   |    (i.e.,    +   is 
evaluated  before  | ). 
Notes: 

(1)  "RPN-query"   is  recursively  defined;  it  is 
either 

a)  "operand8  ,  or 

b)  "argument  +  argument  +  operator". 

In  case  (b),  each  occurrence  of  "argument" 
can  be  replaced  by  either  (a)  or  (b)  and  so 
on.  A  structure  composed  of  operators  and 
operands  conforms  to  the  Type-1  query  syntax 
if  and  only  if  it  is  possible,  by  repeatedly 
replacing  occurrences  of  (b)  with  (a),  to 
reduce  the  structure  to  (a). 

(2)  "operand"  is  either  (a)  attribute-set  +  term,  or 
(b)  Result-set-id.  In  either  case  it  represents 
a  set  of  database  records.  For  (a)  it  is  the  set 
of  database  records  obtained  by  evaluating  the 
specified  attribute-set  and  term  against  the 
collection  of  databases  specified  in  the  Search 
request  (see  Note  3).  For  (b)  it  is  the  set  of 
database  records  represented  by  the  result  set 
for  which  Result-set-id  was  specified  as  the 
value  of  the  parameter  Result-set-name  in  a 
previous  Search  request. 

(3)  Different  attribute  sets  will  be  defined  and 
registered  (Appendix  C  defines  and  registers 
attribute-set  bib-1).  An  example  of  an  attrib- 
ute-set/term combination  is  'title  word'/ 
'evangeline';  in  this  case,  evaluation  of 
attribute-set/term  against  a  database  would 
result  in  the  identification  of  all  of  the  records 
in  the  database  for  which  the  access  point 
'title  word'  contains  the  value  'evangeline'. 

Representation  and  Evaluation  of  the  Tvpe-1  Query 
At  the  origin  system,  the  Type-1  query  is  repre- 
sented by  a  tree.  Each  leaf  node  contains  a  simple 
operand  and  each  non-leaf  node  contains  a  complex 
operand.  A  simple  operand  is  either  a  Result-set-id  or 
an  Attribute-set + Term.  A  complex  operand  is  a 
subtree  whose  root  is  an  operator  and  which  contains 
two  subtrees:  a  left-hand  operand  and  a  right-hand 
operand,  LO  and  RO.  A  complex  operand  is  thus  one 
of  the  following: 

-  LO  AND  RO,  representing  the  intersection  of 
LO  and  RO; 

-  LO  OR  RO,  representing  the  union  of  LO  and 
RO;  or 

-  LO  AND-NOT  RO,  representing  the  set  of 
elements  in  LO  that  are  not  in  RO. 


At  the  target,  evaluation  of  the  tree  is  illustrated 
by  the  use  of  a  stack.  The  tree  is  processed  according 
to  a  left  post-order  traversal.  Each  leaf-node  is  one 
of  the  following: 

a)  Attribute-set  +  Term 

b)  Result-set-id 

c)  Operator 

Whenever  (a)  is  encountered,  it  is  evaluated 
against  the  collection  of  databases  specified  in  the 
Search  request,  and  the  result  is  put  on  the  stack. 
Whenever  (b)  is  encountered,  it  is  put  on  the  stock. 

Whenever  (c)  is  encountered,  the  last  two  items 
(i.e.  sets,  see  Note  2  above)  that  have  been  put  on 
the  stack  are  pulled  off  and  the  operator  is  applied  as 
follows: 

-  if  operator  is  AND,  the  result  is  the  intersec- 
tion of  the  two  sets, 

-  if  operator  is  OR,  the  result  is  the  union  of 
the  two  sets, 

-  if  operator  is  AND-NOT,  the  result  is  the  set 
of  elements  in  the  first  set  (i.e.,  the  first  of 
the  two  sets  to  have  been  placed  on  the  stack) 
which  are  not  in  the  second  set. 

The  resulting  set  is  then  put  on  the  stack. 

When  evaluation  of  the  query  is  complete  (i.e.  all 
query-terms  have  been  processed)  there  will  be  one 
item  remaining  on  the  stack  (otherwise  the  query  is  in 
error)  which  is  the  result  of  the  query. 

The  following  examples  illustrate  query  evalua- 
tion. In  these  examples,  D  represents  the  collection 
of  databases  specified  in  the  Search  request,  R 
represents  a  Result-set-id,  and  A,  B,  and  C  represent 
attribute-list/term  combinations  such  as  "subject  = 
dogs". 

1.  Query    =     A 

Result:  the  records  in  D  for  which  A  is  true 

2.  Query    =    A  B   C  AND  OR 

Result:  the  records  in  D  for  which  both  B  and  C 
are  true,  or  A  is  true 

3.  Query   =   A  B   AND  C  OR 

Result:  the  records  in  D  for  which  both  A  and  B 
are  true,  or  C  is  true 

4.  Query    =     R  A  AND 

Result:  the  records  in  D  for  which  both  (1)  A  is 
true,  and  (2)  Which  are  also  in  result  set  R 

5.  Query    =     R  A  OR 

Result:  the  records  in    D  for  which  A  is  true, 
together  with  records  in  R 

3.2.2.1.2  Database-names  The  target  designates, 
by  agreement  outside  the  scope  of  the  standard,  what 
databases  may  be  specified  on  a  Search  request,  and 
also  in  what  combinations  they  may  be  specified. 


For  example,  a  target  might  specify  that  databases  A, 
B,  and  C,  may  be  searched  individually,  and  that  A 
and  B  may  be  searched  in  combination  (but  not  A 
and  C,  nor  B  and  C).  If  an  origin  requests  a  combi- 
nation of  databases  which  is  not  supported,  the  search 
will  result  in  a  diagnostic  such  as  "combination  of 
specified  databases  not  supported"  (see  appendix  D). 

3.2.2.1.3  Result-set-name  and  Replace-indicator 
The  parameter  Result-set-name  specifies  a  name  to  be 
given  to  the  result  set  which  will  be  created  by  the 
query  so  that  it  may  be  subsequently  referenced 
within  the  same  association. 

o  If  a  result  set  with  the  same  name  already 
exists  at  the  target,  the  action  taken  depends 
on  the  value  of  the  parameter  Replace-indica- 
tor, as  follows: 

If  the  value  of  Replace-indicator  is  "on", 
men  after  processing  the  query,  the  exist- 
ing result  set  whose  name  is  specified  by 
the  parameter  Result-set-name  will  be  de- 
leted, and  a  new  result  set  by  that  name 
created.  If  the  search  cannot  be  processed, 
the  content  of  the  result  set  will  be  empty. 
-     If  the  value  of  Replace-indicator  is  "off, 
the  search  is  not  processed,   an  error 
diagnostic  is  returned  by  the  target,  and 
the  existing  result  set  whose  name  is 
specified  by   the  parameter  Result-set- 
name  is  left  unchanged. 
o     If  a  result  set  does  not  exist  with  the  name 
specified  by  the  parameter  Result-set-name, 
then  a  result  set  by  that  name  is  created  by  the 
target,  and  the  parameter  Replace-indicator  is 
ignored.  The  initial  content  of  the  result  set  is 
empty.  If  no  records  are  found  by  the  query, 
the  result  set  remains  empty. 
A  target  system  need  not  support,  in  general,  the 
naming  of  result  sets  by  the  origin  (see  however 
section  4.4.3,  "Statement  Requirements"  for  Confor- 
mance).   However,  a  target  system  must  support  at 
least  the  result  set  whose  name  is  "default".  If  the 
origin  specifies  "default"  as  Result-set-name,  then 
Replace-indicator  must  be  "on". 

A  result  set  which  is  created  by  a  Search  request 
(that  is,  specified  by  the  parameter  Result-set-name) 
may  be  referenced  in  a  subsequent  Present  request  or 
as  an  operand  in  a  subsequent  Search  request  (for 
example,  in  a  Type-1  query).  If  a  result  set  named 
"default"  is  created,  it  remains  available  for  reference 
from  the  time  it  is  created  until  the  end  of  the  associ- 
ation during  which  it  is  created,  or  until  either: 


-  another  "default0  result  set  is  created,  because 
the  name  "default"  is  specified  as  Result-get- 
name  in  a  subsequent  Search  request,  or 

»  it  is  unilaterally  erased  or  deleted  by  die 
target. 

Any  result  set  other  than  the  result  set  named 
"default"  remains  available  for  reference  from  the 
time  it  is  created  until  it  is  deleted  in  one  of  the 
following  ways: 

-  by  a  Delete  request; 

-  implicitly,  because  a  result  set  was  specified 
by  the  same  name  in  a  Search  request,  and  the 
value  of  the  parameter  Replace-indicator  was 
"on"; 

-  unilaterally  by  the  target  (at  any  time);  or 
by  termination  of  the  association. 

3.2.2.1.4  Small-set-element-set-names  and  Medi- 
um-set-element-set-names An  element  set  name  is  a 
primitive  name  which  specifies  a  particular  subset  of 
the  elements  in  a  database  record  which  are  to 
compose  the  response  records.  The  specified  subset 
is  made  up  of  components  of  the  abstract-syntax 
description  of  the  database  records  and  is,  therefore, 
a  formal  subset  of  that  abstract-syntax -definition.' 
Element  set  names  are  specified,  along  with  their 
definitions,  for  a  given  database,  by  the  target, 
outside  of  this  standard.  The  target  specifies  a  default 
element  set  for  each  database. 

The  parameters  Small-set-element-set-names  and 
Medium-set-element-set-names  describe  the  preferred 
composition  of  the  records  expected  in  the  search 
response.  If  the  query  results  in  a  small-set  (see 
3 .2.2. 1 . 6) ,  then  Small -set-element-set-names  pertains. 
If  the  query  results  in  a  medium-set,  then  Medium- 
set-element-set-names  pertains. 

Each  of  the  two  parameters  is  a  set  of  one  or  more 
pairs  of  a  database  name  and  associated  element  set 
name.  For  each  database  record  returned  in  a  Search 
(or  Present)  response,  if  the  given  database  is  speci- 
fied (as  a  component  of  one  of  the  pairs  comprising 
the  pertaining  element  set  name)  then  the  response 
record  should  be  composed  according  to  the  corre- 
sponding element  set  name.  If  not,  the  response 
record  should  be  composed  according  to  the  default 
element  set  name  for  that  database.  If  an  element  set 
name  is  specified  which  is  not  valid  for  the  corre- 
sponding database,  then  the  Search  Response  will 
'  include  a  diagnostic,  such  as  "element  set  name  not 
valid  for  database",  and  the  value  of  the  parameter 
Search-Status  will  be  "failure". 

Each  of  the  two  parameters  may  alternatively 
consist  of  a  single  element  set  name  (from  those 


defined  by  the  target  system),  with  no  database 
specified.  In  that  case,  for  each  database  record 
returned  in  a  Search  (or  Present)  response: 

-  if  the  specified  element  set  name  is  valid  for 
the  given  database,  the  response-record  should 
be  composed  according  to  that  element  set 
name; 

-  if  the  specified  element  set  name  is  not  valid 
for  the  given  database,  the  response-record 
should  be  composed  according  to  the  default 
element  set  name  for  that  database. 

A  target  system  must  always  recognize  the  charac- 
ter string  T"  as  an  element  set  name  to  mean  "full 
record".  When  a  "full  record"  is  requested,  the 
target  returns  all  of  the  elements  stored  in  its  database 
for  the  requested  record.  For  a  given  record,  the  set 
of  elements  included  in  a  "full  record"  in  one  data- 
base might  not  be  the  same  set  of  elements  included 
in  a  "full  record"  in  another  database.  (The  target 
may  use  "F"  as  the  default  element  set  name.) 

3.2.2. 1.5  Freferred-record-syntax  The  parameter 
Preferred-record-syntax  identifies  the  preferred 
abstract  syntax  for  the  records  to  be  returned,  from 
among  the  set  of  abstract  syntaxes  for  records  for 
which  presentation  contexts  are  currently  established 
for  this  application  association.  If  the  target  cannot 
supply  the  information  in  the  requested  abstract 
syntax,  it  will  supply  it  in  one  of  the  other  abstract 
syntaxes  from  the  established  set. 

3.2.2.1.6  Small-set-upper-bound,  Large-set-lower- 
bound,   and  Medium -set-present-number      The 

result  set  is  considered  a  "small-set",  "medium-set", 
or  "large-set",  depending  on  the  values  of  parameters 
Small-set-upper-bound  and  Large-set-lower-bound  of 
the  Search  request,  and  Result-count  of  the  Search 
response  (see  section  3.2.2.1.8).  The  result  set  is  a 
small-set  if  Result-count  is  not  greater  than  small-set- 
upper-bound.  The  result  set  is  a  large-set  if  Result- 
count  is  larger  than  or  equal  to  Large-set-lower- 
bound.  Otherwise,  the  result  set  is  a  medium-set. 

If  the  query  results  in  a  small-set,  all  database 
records  identified  by  the  result  set  are  to  be  returned 
to  the  origin  (subject  to  possible  message  size  con- 
straints). If  the  query  results  in  a  large-set,  no 
database  records  are  to  be  returned.  If  the  query 
results  in  a  medium-set,  the  maximum  number  of 
database  records  to  be  returned  is  specified  by 
Medium-set-present-number. 
Notes: 

(1)   The  result  set  may  be  a  medium-set  only  when 
Result-count  is  greater  than  small-set-upper- 


bound  and  less  than  Large-set-lower-bound, 
and  this  can  occur  only  if  Large-set-lower- 
bound  is  at  least  2  greater  than  Small-set- 
lower-bound;  i.e.,  the  result  set  cannot  be  a 
medium-set  if  Large-set-lower-  bound  exceeds 
Small-set-upper  bound  by  one.  For  example, 
if  Large-set-lower-bound  is  1 1  and  Small-set- 
upper-bound  is  10,  the  intent  is  "if  10  or  less 
records  are  found  return  them  all,  otherwise 
do  not  return  any",  and  medium-set-present- 
number  would  not  apply. 

(2)  Small-set-upper-bound  may  be  zero.  Large- 
set-lower-bound  must  be  greater  dun  Small- 
set-upper-bound. 

(3)  If  the  origin  does  not  want  my  records  re- 
turned in  the  response  regardless  of  the  value 
of  Result-count,  Larger-set-lower-bound 
should  be  set  to  1  and  Small-set-upper-bound 
to  zero. 

3.2.2.1.7  Database/diagnostic-records  The  target 
processes  the  search,  creating  a  result  set  which 
identifies  a  set  of  database  records.  It  cannot  be 
assumed  however  that  search  processing  requires 
physical  access  to  the  database  records;  thus  one  or 
more  records  might  not  be  returnable,  but  this 
circumstance  might  not  be  recognized  until  an  attempt 
is  made  to  transfer  such  a  record. 

After  processing  the  search,  the  target  attempts  to 
retrieve  the  first  N  records  identified  by  the  result 
set,  to  be  included  in  the  Search  response  (N  de- 
pends on  the  search  parameters  and  result-count,  as 
described  in  3.2.2.1.6).  For  each  record  which 
cannot  be  returned,  a  surrogate  diagnostic  record  is 
substituted.  Thus  the  parameter  Database/diagnostic- 
records  is  one  of  the  following: 

-     N  database  and/or  diagnostic  records, 

a  number  of  database  and/or  diagnostic  re- 
cords, which  is  less  than  N  because  of  mes- 
sage size  constraints  (see  3.3); 
a  single  non-surrogate  diagnostic  record  indi- 
cating that  the  search  cannot  be  processed, 
and  why  it  cannot  be  processed;  or 
a  single  non-surrogate  diagnostic  record  indi- 
cating that  records  cannot  be  presented,  and 
why  not,  e.g.  "element  set  name  not  valid  for 
database". 
The  order  of  occurrence  of  records  (database 
and/or  surrogate  diagnostic)    within  the  parameter 
Database/diagnostic-records  is  according  to  the  order 
in  which  they  are  identified  by  the  result  set.   Each 
database  or  surrogate  diagnostic  record  may  optional- 
ly be  accompanied  by  the  name  of  the  database  in 


which  the  record  resides.  However,  the  database 
same  must  accompany  the  first  database  or  surrogate 
diagnostic  record  being  returned,  and  must  accompa- 
ny any  record  coming  from  a  database  different  than 
its  immediate  predecessor. 

3.2.2.1.8  Result-count  and  Number-of-records- 
returned  The  parameter  Result-count  is  the  number 
of  records  identified  by  the  result  set.  If  the  result 
set  is  empty,  result-count  is  zero.  The  parameter 
Number-of-records-retumed  is  die  total  number  of 
records  (database  and  diagnostic)  returned  in  the 
Search  response. 

3.2.2.1.5  Next-muIt-set-positiQn  The  parameter 
Next-result-set-position  specifies  the  position  within 
the  result  set  of  the  next  record  following  those 
returned  (or  zero  if  the  last  record  in  the  result  set  is 
being  returned). 

3.2.2.1.10  Search-status  The  parameter  Search- 
status,  returned  in  the  response,  assumes  one  of  the 
following  two  values: 

success        -     the  search  completed  successfully 
failure         -     the  search  did  not  complete  suc- 
cessfully 
A  value  of  "success"  does  not  imply  that  the 
expected  database  and/or  surrogate  diagnostic  records 
are  being  returned  as  part  of  the  response  (see 
Present-status,  3.2.2.1.11).  Note  also,  a  value  of 
"success"   does  not  imply  that  any  records  were 
located  by  the  search.     A  value  of  "failure"  does 
imply  that  none  of  the  expected  database  and/or 
surrogate  diagnostic  records  is  being  returned.  In  the 
latter  case,   the  target  returns  a  single  diagnostic 
record  indicating  that  the  search  cannot  be  processed. 

3.2.2.1.11  Result-set-status  and  Present-status 
These  are  status  descriptors  necessary  to  dissam- 
biguate  certain  situations  that  can  occur  during  search 
and  present  operations. 

Result-set-status  occurs  if  and  only  if  the  value  of 
Search-status  is  "failure",  and  its  value  is  one  of  the 
following: 

subset   -     Partial,  valid  results  available. 

interim  -  Partial  results  available,  not  necessari- 
ly valid. 

none  -  No  results  available  (result  set  is 
empty). 

Present-status  occurs  if  and  only  if  the  value  of 
Search-status  is  "success",  and  its  value  is  one  of  the 
following: 
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success  -  All  of  the  expected  database  (or 
surrogate  diagnostic)  records  are 
available. 

partial- 1  -  Not  all  of  the  expected  records 
can  be  returned  because  the  re- 
quest was  terminated  by  access- 
control. 

partial-2  -  Not  all  of  the  expected  records 
can  be  returned  because  the  re- 
quest was  terminated  by  maxi- 
mum message  sue. 

partial-3  -  Not  all  of  the  expected  records 
can  be  returned  because  the  re- 
quest was  terminated  by  resource- 
control  at  origin. 

partial-4  -  Not  all  of  the  expected  records 
can  be  returned  because  the  re- 
quest was  terminated  by  resource- 
control  at  target. 

failure  -  None  of  the  expected  database  (or 
surrogate  diagnostic)  records  can 
be  returned.  A  single  diagnostic 
is  returned,  which  is  not  a  surro- 
gate for  a  database  record. 

3.2.2.1.12  Reference-id   See  section  3.4 
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Table  3:  Parameters  of  the  Present  Service 


3*2.3  Retrieval  Facility 

The  Retrieval  facility  enables  the  origin  to  retrieve 
a  copy  of  records  according  to  position  within  a 
result  set  maintained  by  the  target. 

3.23.1  Present  Service 

The  Present  service  allows  the  origin  system  to 
retrieve  records  from  a  specified  result  set.  Records 
are  referenced  by  relative  position  within  the  result 
set.  The  origin  specifies  a  range  of  records  to  be 
retrieved  and  may  follow  with  subsequent  requests 
specifying  different  ranges.  For  example,  the  origin 
may  retrieve  records  one  through  five  and  follow 
with  a  request  for  records  four  through  six. 

3.2.3.1.1  Number-of -records-requested  and 
Result-set-start-position  The  origin  requests  the 
return  of  N  records  beginning  at  record  M,  from  the 
result  set,  where  N  =  Number-of-records-requested 
and  M  =  Result-set-start-position  (and  N  is  sot 
greater  than  (Result-count  -  M)  +  1). 

3.2.3.1.2  Result-set-id  Result-set-id  specifies  the 
result  set  from  which  records  are  to  be  retrieved.   It 


is  the  result  set  created  by  a  previous  Search  request 
for  which  the  value  of  the  parameter  Result-set-name 
matches  the  value  of  Result-set-id. 

3.2.3.1.3  Element-set-names  The  parameter 
Element-set-names  describes  the  preferred  composi- 
tion of  the  records  expected  in  the  Present  response. 
See  section  3.2.2.1.4. 


3.2.3.1.4 
3.2.2.1.5. 


Preferred-record-syntax     See  section 


3.2.3. 1.5  Database/diagnostic-records  The  param- 
eter Database/diagnostic-records  returned  by  the 
target  consists  of  one  of  the  following: 

-     N  database  and/or  diagnostic  records,  where 
N  =  Number-of-records-requested, 
a  number  of  database  and/or  diagnostic  re- 
cords, which  is  less  than  N  (reason  specified 
by  Present-status),  or 

a  single  diagnostic  record  indicating  that  the 

request   cannot  be  processed,   and  why  it 

cannot  be  processed. 

The  order  of  occurrence  of  records  (database 

and/or  surrogate'  diagnostic)    within  the  parameter 
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Database/diagnostic-records  is  according  to  the  order 
in  which  they  are  identified  by  the  result  set.  Each 
database  and/or  surrogate  diagnostic  record  may  op- 
tionally be  accompanied  by  the  name  of  the  database 
in  which  the  record  resides.  However,  the  database 
name  must  accompany  the  first  record  being  re- 
turned, and  must  accompany  any  record  coming  from 
a  database  different  than  its  immediate  predecessor. 

3.2.3.1.6  Number-of-records-returaed  and  Nort- 
result-sei-position  The  parameter  Number-of-rec- 
ords-retumed  is  the  total  number  of  database  and 
diagnostic  records  returned.  Next-result-set-position 
is  the  position  within  the  result  set  of  die  next  record 
following  the  last  database  or  surrogate  diagnostic 
record  being  returned  (or  zero,  if  the  last  database  or 
surrogate  diagnostic  record  in  the  result  set  is  being 
returned). 

3.2.3.1.7  Present-status  Present-status  is  mandatory 
in  a  Present  response  and  its  values  are  the  same  as 
those  listed  for  Present-status  in  3.2.2.1.11. 

3.2.3.1.8  Reference-id   See  section  3.4. 


3X4  ResuK-set-delete  Facility 

The  Result-set-delete  facility  enables  an  origin  to 
instruct  a  target  system  to  delete  one  or  more  result 
sets  known  to  the  target..  The  target  responds  with 
information  pertaining  to  the  result  of  the  operation. 

3.2.4.1  Delete  Service 

The  Delete  service  enables  an  origin  system  to 
send  a  Delete  request  to  the  target.  The  origin  may 
request  deletion  of  specified  result  sets  held  by  the 
target  or  all  result  sets  currently  on  the  target  created 
during  this  association.  The  target  responds  by 
reporting  the  status  of  the  requested  delete  operation. 

3.2.4.1.1  Delete-operation  The  origin  specifies  one 
of  the  following: 

list  -     delete     one  or  more  specified 

result  sets  (see  3.2.4.1.2),  or 

bulk-delete  -  delete  all  result  sets  currently  on 
the  target  system  created  during 
this  association. 

3.2.4.1.2  Result-set-list  If  Delete-operation  is 
"list",  then  the  parameter  Result-set-list  must  be 
present.  It  specifies  a  list  of  result  sets  to  be  deleted, 
which  were  created  by  previous  Search  requests  (in 
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Deiete-msg 
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Reference-M 
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llflfK 
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Table  4:  Parameters  of  the  Delete  Service 


which  the  value  of  the  parameter  Result-set-name 
matches  the  value  of  one  of  the  members  of  the  list). 
If  Delete-operation  is  "bulk-delete",  then  die  param- 
eter Result-set-list  must  not  be  present. 

3.2.4.1.3  Delete-operation-status  Delete-operation- 
status  is  used  by  the  target  to  report  the  status  of  the 
delete  request.  It  assumes  one  of  the  values  "success" 
or  "failure-3"  through  "failure-9"  in  table  5. 

3.2.4.1.4  Delete-list-statuses  Delete-list-statuses  is 
present  in  a  Delete  response  for  a  list  operation.  It 
contains  the  same  Result-set-  id(s)  contained  in  the 
Result-set-list  parameter  of  the  corresponding  Delete 
request.  Each  result-set-id  in  the  Delete-list-statuses 
parameter  is  paired  with  a  status.  Possible  status 
values  are  "success"  and  "failure-1"  through  "failure- 
6"  in  table  5. 

3.2.4.1.1  Number-not-deleted  and  Bulk-statuses 
These  two  parameters  occur  only  if  Delete-operation 
is  Bulk-delete  and  if  Delete-operation-status  = 
8failure-8".  The  parameter  Number-not-deleted  indi- 
cates how  many  result  sets  were  not  deleted,  and  die 
parameter  Bulk-statuses  gives  individual  statuses  for 
those  not  deleted. 

Note,  however,  that  a  target  system  is  not  obligat- 
ed to  provide  statuses  for  each  result  set  not  deleted 
on  a  bulk  delete.  For  example,  a  target  system  may 
abort  a  bulk  delete  when  the  first  failure  to  delete  a 
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Status    fiescripjion. 
success    Result  set(s)  deleted, 
failure-!    Result  set  did  not  exist. 

failure-2    Result  set  previously  unilaterally 

yi;|;|;i:;;y|y::;.:'-deleted  by  target. 

failure-3    System  problem  at  target  (optional 
text  message  may  be  included  in 
WMMMtm  the"  Delete-msg  parameter) . 

foilure-4    Access-control  failure:  fee  delete 

.   request  caused  the  target  system  to .:;: 
issue  an  Access -control  request 
which  the  origin system [failed  to ||| 
satisfy,  or  the  origin  could  not 
■^{accept  an  Access-control  request. 

failure-5    Request  terminated  by  origin  sys- 
W^W:''':)\M':tem  through  resource  control. 

failure-6    Access  terminated  by  target  system:: 
due  to  resource  constraints. 

failure-7    Bulk  delete  of  result  sets  not  sup- 
-_.r:'iy=-  -_;  M-X'-"-"'-:-! :"  ported  by  target. 

failure-8    Not  all  result  sets  deleted  (on  a 
bulk-delete  request)  (see  3.2.4.- 
1.5). 

Failure-9    Not  all  requested  r^t  sets  delepil 
v.:;X(on  •  list  request). 

Note:  failure-7  and  failure-8  can  occur  only  if 
Delete-operation  is  Bulk-delete. 


Table  5:  Delete  statuses 


result  set  that  is  part  of  the  bulk  delete  fails;  in  this 
case  only  a  single  status  might  be  included  in  the 
parameter  Bulk-statuses. 

If  a  bulk  delete  results  in  more  statuses  than  can 
fit  into  a  single  Delete-response  message,  the  target 
system  may  discard  those  which  do  not  fit. 

3.2.4.1.6  Delete-msg  Delete-msg,  if  present,  contains 
an  optional  text  message. 

3.2.4.1.7  Reference-id  See  section  3.4. 


3X5  Access  Control  Facility 

The  Access-control  facility  allows  •  target  system 
to  challenge  an  origin  system  during  execution  of  an 
Init,  Search,  Present,  Delete,  or  Resource-report 
operation. 

32SA  Access-control  Service 

An  origin  system  must  be  prepared  to  accept  and 
respond  to  one  or  more  Access-control  requests  while 
an  Init,  Search,  Present,  Delete,  or  Resource-report 
request  is  being  executed  by  the  target  system  (unless 
fee  parameter  Options  of  fee  Init  request  which 
initiated  fee  connection  did  not  include  Access- 
control;  see  3.2.1.1.2).  For  example,  after  sending 
a  Search  request,  the  origin  must  be  prepared  to 
receive  an  Access-control  request,  respond  wife  an 
Access-control  response,  then  later  receive  another 
Access-control  request,  etc.,  before  receiving  a 
Search  response. 

Once  fee  origin  has  responded,  fee  operation 
proceeds  as  if  the  challenge  has  never  taken  place. 
If  the  origin  system  fails  to  respond  correctly  to  the 
challenge  during  a  Search,  Present,  Delete,  or 
Resource-report  request,  then  the  respective  response 
may  indicate  that  the  operation  was  terminated  due  to 
an  Access-control  failure.  (Note:  During  a  Search  or 
Present  operation,  while  fee  target  is  preparing 
records  for  presentation,  it  might  send  an  Access 
Control  request  pertaining  to  a  particular  record.  If 
the  origin  fails  to  respond  correctly  to  fee  challenge, 
fee  target  may  simply  substitute  a  surrogate  diagnos- 
tic: "security  challenge  failed;  record  not  included0.) 
If  fee  origin  system  fails  to  respond  correctly  to  fee 
challenge  during  an  Init  request,  the  target  may  set 
fee  Result  parameter  to  "reject"  and  may  (optionally) 
supply  such  an  indication  in  the  User-infonnation- 
field  of  fee  Init  response. 

The  Access-control  request/response  mechanism 
can  be  used  to  support  password  challenges,  public 
key  cryptosystems,  algorithmic  authentication,  etc. 
The  specific  content  of  the  Access-control  request  and 
response  parameters  are  outside  the  scope  of  this 
standard. 

3.2.5.1.1  Security-challenge  and  Security-chal- 
lenge-response  The  contents  of  these  two  parameters 
are  outside  fee  scope  of  this  standard  and  must  be 
established  by  prior  agreement  between  •  given 
target/origin  system  pair. 

3.2.5.1.2  Reference-id  See  section  3.4. 
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Table  6:  Parameters  of  the  Access  Control  Service 

3*2.6  Accosting/Resource  Control 

Facility 

The  Accounting/Resource  Control  facility  consists 
of  the  Resource-control  service  (initiated  by  the  target 
during  a  Search,  Present,  or  Delete  operation),  the 
Trigger-resource-control  service  (initiated  by  the 
origin  during  a  Search,  Present,  or  Delete  operation), 
and  the  Resource-report  service  (initiated  by  the, 
origin  when  no  operation  is  pending). 

The  Resource-control  service  permits  the  target 
system  to  send  a  Resource-report,  notifying  the  origin 
system  when  either  actual  or  predicted  resource 
consumption  will  exceed  agreed  upon  limits  (or  limits 
built  into  the  target  system),  and  to  obtain  the  origin 
system's  consent  to  continue  the  operation.  In 
addition,  the  target  system  can  inform  the  origin 
system  about  the  current  status  of  a  result  set  being 
generated  on  the  target  in  response  to  a  Search 
request,  and  indicate  information  about  the  status  of 
the  current  request  to  the  origin. 

The  Trigger-resource-control  service  permits  the 
origin  system  to  request  that  the  target  initiate  the 
Resource-control  service,  or  cancel  the  current 
operation. 

When  no  operation  is  pending,  the  Resource-report 
service  permits  the  origin  system  to  request  that  the 
target  send  a  Resource-report. 

3.2.6.1  Resource-control  Serwce 

A  target  system  may  issue  a  Resource-control 
request  following  receipt  of  an  Init,  Search,  Present, 
or  Delete  request,  prior  to  issuing  the  corresponding 
Init,  Search,  Present,  or  Delete  response. 

The  target  indicates  whether  a  response  to  the 
request  is  required: 


-  If  the  target  indicates  that  a  response  is  re- 
quired, the  origin  system  must  issue  a  Re- 
source-control response.  The  target  awaits  the 
Resource-control  response,  and  subsequently 
issues  the  Init,  Search,  Present,  or  Delete  re- 
sponse, after  processing  of  the  operation  is 
concluded. 

-  If  the  target  indicates  that  a  response  is  not 
required,  the  origin  system  must  not  issue  a 
Resource-control  response,  and  the  target 
subsequently  issues  the  Init,  Search,  Present, 
or  Delete  response,  after  processing  of  the 
operation  is  concluded. 

An  origin  should  be  prepared  to  receive,  and 
(conditionally)  respond  to,  multiple  Resource-control 
requests  during  the  execution  of  an  Init,  Search, 
Present,  or  Delete  request. 

If  the  origin  responds  to  a  Resource-control 
request  with  a  Resource-control  response  saying  to 
terminate  the  operation,  it  can  expect  to  receive  an 
Init,  Search,  Present,  or  Delete  response.  This 
response  might  indicate  that  the  operation  was  termi- 
nated at  origin  request.  However,  the  response  might 
alternately  indicate  that  the  operation  completed, 
since  the  operation  at  the  target  system  may  continue 
to  execute  and  subsequently  complete  before  the  Re- 
source-control response  reaches  the  target  system. 
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Table  7:  Parameters  of  the  Resource  Control  Service 

3.2.6.1.1  Resource-report  Resource-report  may  be 
used  to  convey  information  about  the  current  and 
estimated  resource  consumption  at  the  target  system. 
The  format  of  Resource-report  bib-1  is  defined  in 
Appendix  F. 
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3.2.6.1.2  Partial-results-available  Hie  target 
indicates  the  status  of  the  result  set  via  the  flag 
Partial-results-available,  whose  value  is  one  of  the 
following: 

subset    -     Partial,  valid  results  available. 

interim  -     Partial  results  available,  not  necessary 
valid. 

none      -     No  results  available. 

This  parameter  is  meaningful  only  during  a  search 
operation.  If  its  value  is  "subset''  or  "interim0,  then 
the  target  will  accept  subsequent  Present  requests  if 
the  current  request  is  terminated  by  the  Resource- 
control  response,  and  if  the  value  of  the  parameter 
Result-set-wanted  is  "on". 

If  the  value  of  Partial-results-available  is  "none" 
■  then  the  target  need  not  accept  subsequent  Present 
requests  in  the  event  that  the  request  is  terminated  by 
the  Resource-control  response. 

Note  that  if  Suspended-flag  is  off,  the  partial 
results  available  situation  may  change  since  process- 
ing continues  on  the  search.  In  all  cases,  the  values 
of  Search-status  and  Result-set-status  in  the  Search 
response  should  be  treated  as  the  authoritative  infor- 
mation. 

3.2.6.1.3  Suspended-flag  The  target  system  indi- 
cates whether  or  not  processing  of  the  command  has 
been  suspended  pending  the  Resource-control  re- 
sponse. This  flag  occurs  if  and  only  if  the  value  of 
Response-required  is  "yes". 

3.2.6.1.4  Response-required  The  target  system 
indicates  whether  or  not  a  response  (from  the  origin) 
to  this  request  is  required. 

3.6.2.1.5  Trigg ered-request-flag  The  target  system 
may  optionally  indicate  whether  or  not  this  request 
resulted  from  a  Trigger-resource-control  request  from 
the  origin. 

3.2.6.1.6  Continue-flag  The  origin  indicates  to  the 
target  whether  or  not  to  continue  processing. 

3.2.6.1.7  Result-set-wanted  This  flag  is  meaning- 
ful only: 

during  a  Search  request, 

-  when  the  value  of  Partial -results-available  is 
"subset"  or  "interim",  and 

-  when  the  value  of  the  parameter  Continue-flag 
is  "do  not  continue". 

If  the  value  of  the  flag  is  "on",  the  target  will 
maintain  the  (possibly  partial)  result  set  for  subse- 
quent Present  requests.    If  the  value  of  the  flag  is 


"off",  the  target  may  delete  the  result  set.  A  result 
get  status  of  "none"  on  the  subsequent  Search  re- 
sponse indicates  that  the  target  has  discarded  the 
result  set.  In  all  cases,  the  values  of  Search-status 
and  Result-set-status  in  the  Search  response  describe 
the  actual-  decisions  made  by  the  target  system  and 
the  way  in  which  the  search  terminated. 

3.2.6.1.8     Refermee-id  See  iection  3.4. 

3.2.6.2  Trigger-resonr»-c®iitrol  Semce 
An  origin  system  may  issue  a  Trigger-resource- 
control  requests  following  an  Init,  Search,  Present,  or 
Delete  request,  prior  to  receipt  of  the  corresponding 
response.  The  request  serves  as  •  signal  to  the  target 
system  that  the  origin  wishes  the  target  to: 

a)  simply  send  a  Resource-report  -  i.e.  issue  a 
Resource-control  request  with  Response-re- 
quired "off"; 

b)  invoke  full  resource  control  -  i.e.  issue  a 
Resource-control  request  with  Response-re- 
quired "on";  or 

c)  Cancel  the  current  Init,  Search,  Present,  or 
Delete  operation. 

The  target  is  not  obligated  to  take  any  specific 
action  upon  receipt  of  a  Trigger-resource-control 
request.  For  the  purpose  of  procedure  description, 
there  is  no  response  to  the  request;  if  the  target 
wishes  to  issue  a  Resource-control  request  it  does  so 
unilaterally.  (If  the  origin  issues  a  Trigger-resource- 
control  request  and  subsequently  receives  a  Resource- 
control  request,  the  origin  cannot  necessarily  deter- 
mine whether  the  latter  resulted  from  the  Trigger- 
resource-control  request.  However,  the  target  may 
include  Triggered-request-flag  in  the  Resource- 
control-request  to  so  indicate.) 

If  the  origin  issues  a  Trigger-resource-control 
request  saying  to  cancel  the  command,  and  if  the 
target  honors  the  request,  the  origin  can  expeqt  to 
receive  an  Init,  Search,  Present,  or  Delete  response 
indicating  that  the  request  was  terminated  at  origin 
request. 

Although  an  origin  system  may  issue  a  Trigger- 
resource-control  request  only  prior  to  receipt  of  an 
Init,  Search,  Present,  or  Delete  response,  the  target 
might  issue  such  a  response  before  it  receives  the 
Trigger-resource-control  request;  In  that  case,  the 
target  will  ignore  the  Trigger-resource-control  re- 
quest. Furthermore,  the  target  might  receive  a 
Trigger-resource-control  request  after  issuing  a 
Resource-control  request,  while  awaiting  a  Resource- 
control  response.  In  that  case,  again,  the  target 
should  ignore  the  Trigger-resource-control  request. 
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(Note  that  in  general,  the  target  may  ignore  my 
Trigger-resource-control  request.) 


Parameter  OrjfiJLReguest 

Requested-operation  s 

■;  Prefcrred-rsMouroe-  s  (if  applicable) 

;';j|;S;v:K;.report-fQnnat 

Result -set-wanled  s  (if  applicable) 

Reference-id  s  (if  applicable) 


Table  8:  Parameters  of  the  Trigger  Resource  Control 
Service 

3.2.6.2.1  Requested-operation  The  origin  indicates 
one  of  the  following: 


resource-report 


resource-control 


cancel 


issue  a  Resource-control 
request  and  set  Response- 
required  to  "off; 
issue  a  Resource-control 
request  and  set  Response- 
required  to  "on"; 
Terminate  the  current 
Init,  Search,  Present,  or 
Delete  operation. 


3.2.6.2.2  Preferred-Resource-report-format  This 
parameter  is  meaningful  only  when  the  value  of  the 
parameter  Requested-operation  is  "resource-control" 
or  "resource-report".  It  identifies  a  resource  report 
format  that  the  origin  prefers. 

3.2.6.2.3  Result-set-wanted  This  flag  is  meaningful 
only  during  a  Search  request  and  when  the  value  of 
the  parameter  Requested-operation  is  "cancel".  If  the 
value  of  the  flag  is  "on",  the  origin  requests  that  the 
target  maintain  the  (possibly  partial)  result  set  for 
subsequent  Present  requests.   See  section  3.2.6.1.7. 

3.2.6.2.4  Reference-id  See  section  3.4. 

3.2.6.3  Resource-report  Serrae 

The  origin  may  issue  a  Resource-report  request 

following  receipt  of  an  Init,  Search,  Present,  or 

Delete  response  from  the  target.  The  target  responds 

with  a  Resource-report  response. 

Note:  The  Resource-report  service  is  a  confirmed 
service  and  as  such  differs  from  the  Trigger- 
resource-control  service,  which  is  non-confirmed. 
The  origin  may  invoke  the  Resource-report  service 


only  in  the  "open"  state,  that  is,  following  the 
conclusion  of  an  operation  (Init,  Search,  Present, 
Delete,  or  Resource-report)  and  prior  to  initiation 
of  a  subsequent  operation.  Therefore  a  Resource- 
report  request  from  the  origin  requires  a  response 
from  the  target.  (If  the  response  were  not  determi- 
nable, then  the  origin  would  not  be  certain  when 
to  initiate  a  subsequent  operation.  In  contrast, 
when  the  origin  issues  a  Trigger-resource-control 
request,  it  awaits  an  action  from  die  target  — 
either  a  Resource-control  request  or  an  operation 
response  —  and  therefore  the  lack  of  a  determinis- 
tic response  does  not  present  sequencing  prob- 
lems.) However,  although  the  target  is  obliged 
send  a  Resource-report  response,  the  target  is  not 
obliged  to  include  a  resource-report  in  the  Re- 
source-report response. 


Parameter 

OiiRin 

Target 

Pref erred  -resource- 
rcport-fonnat 

X<opL) 

Resource-repori- 

stalUB 

llllliiiiiiiiiiiii 

llljlllJljfResowt^^^ep^l 

*(opt.) 

Refcreace-kt 

x(opu) 

X(ifappl.) 

Table  9:  Parameters  of  the  Resource  Report  Service 

3.2.6.3.1  Preferred-resource-report-format  Identi- 
fies a  resource  report  format  that  the  origin  prefers. 

3.2.6.3.2 Resource-report-status  The  target  supplies 
one  of  following  status  values: 

success  -  A  resource  report  is  included  (and 
in  the  preferred  format,  if  the 
parameter  Preferred-resource- 
report-format  was  included  in  the 
request). 

partial  -  A  resource  report  is  included,  but 
not  in  the  preferred  format  (ap- 
plies only  if  the  parameter  Pre- 
ferred-resource-report-format  was 
included  in  the  request). 

failure- 1  -  Target  unable  to  supply  resource 
report. 

fidlure-2  -  Access  terminated  by  target  due 
to  resource  constraints. 

failure-3      -     Access-control  failure. 

failure-4      -     Unspecified  failure. 
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3.2.6.3.3  Resourcs-report   See  3.2.6.1.1. 

3.2.6.3.4  Refereace-id   See  section  3.4. 


3X7  Termination  Facility 

The  Termination  Facility  allows  either: 

(1)  an  origin  or  target  to  initiate  abrupt  termina- 
tion of  the  association  via  the  IR-abort  service 
element,  or 

(2)  an  origin  to  initiate  graceful  termination  via 
the  IR-release  service. 

The  IR-abort  and  IR-release  services  map  directly 
onto  the  A- ABORT  and  A-RELEASE  services  of  the 
association  control  service  element. 

3.2.7.1  IR-abort  Service 

Either  the  origin  or  target  may  at  any  time  either 
send  or  receive  an  IR-abort  request,  and  consider  the 
application  association  terminated. 

3.2.7.2  IR-Release  Service 

The  origin  may  invoke  an  IR-release  request 
following  receipt  of  an  Init,  Search,  Present,  Delete, 
or  Resource-report  response.  It  should  then  await ' 
receipt  of  an  IR-Release  response,  and  then  consider 
the  association  terminated.  Alternately,  it  might 
receive  an  IR-abort  request  from  the  target,  in  which 
case  it  should  consider  the  application  association 
terminated. 

The  target  may  receive  an  IR-release  request  after 
sending  an  Init,  Search,  Present,  Delete,  or  Re- 
source-report response.  It  should  then  send  an  IR- 
release  response,  and  consider  the  association  termi- 
nated. 


33  Message  Size  limitations 

For  both  the  Search  and  Present  services,  it  is 
possible  that  the  target  will  not  be  able  to  return  the 
number  of  database  records  requested  because  of 
message  size  limitations.  In  that  case,  the  target  is 
responsible  for  packing  as  many  records  as  possible 
into  the  response  message.  (Note:  A  response 
message  always  contains  an  integral  number  of 
records;  a  record  never  spans  response  messages.) 

Illustration 

Assume  that  the  target  is  attempting  to  transmit 
records  in  result  set  positions  1  through  10  (in  this 
section,  the  term  "record"  means  "database  or  surro- 


gate diagnostic  record",  unless  "diagnostic  record"  or 
"database  record"  is  specified).  Assume  further  that: 
records  in  position  1  through  6  fit  in  the 
response  message,  such  that  the  sum  of  the 
sizes  of  die  records  (not  including  any  proto- 
col control  information)  does  sot  exceed 
Preferred-message-size;  but, 
the  database  record  in  position  7  will  not  fit 
in  the  message  along  with  records  in  position 
1  through  6  without  the  resulting  sum  of  the 
message  sizes  exceeding  Preferred-message- 
size. 
The  size  of  the  database  record  in  position  7: 

(a)  does  not  exceed  Preferred-message-size, 
or 

(b)  exceeds  Preferred-message-size,  but  does 
not  exceed  Maximum-record-size,  or 

(c)  exceeds  Maximum-record-size. 

In  case  (a),  the  target  returns  records  in 
position  1  through  6.  In  case  (b),  except  as  noted 
below  (see  "Exception"),  the  target  substitutes  a 
diagnostic  record  for  the  database  record  in  position 
7,  indicating  mat  the  record  exceeds  Preferred- 
message-size.  In  case  (c)  the  target  substitutes  a 
diagnostic  record  for  the  database  record  in  position 
7,  indicating  that  the  record  exceeds  Maximum- 
record-size.  (If  Maximum-record-size  equals  Pre- 
ferred-message-size then  there  is  no  distinction 
between  the  meaning  of  the  two  diagnostics.) 

In  case  (b)  or  (c)  if  the  diagnostic  record  will  not 
fit  along  with  the  records  in  position  1  through  6, 
me  target  returns  the  records  in  position  1  through  6. 
(Preferred-message-size  must  always  be  large  enough 
to  contain  any  diagnostic  record;  thus  a  subsequent 
present  request  beginning  with  the  record  in  position 
7  will  retrieve  the  diagnostic.)  Otherwise,  the  target 
inserts  the  diagnostic  record  and  proceeds  to  attempt 
to  fit  records  in  positions  8  through  10  into  the 
response  message. 

Exception 

If  a  Present  request  specifies  a  single  record  (i.e. 
Number-of-records-requested  equals  1)  men  if  the 
size  of  that  record  exceeds  Preferred-message-size, 
but  does  not  exceed  Maximum-record-size,  the  target 
will  return  that  single  database  record  in  the  Present 
response.  Note  that  this  exception  applies  only  to  a 
Present  request  and  not  to  a  Search  request. 

Thus  in  case  (b),  the  origin  may  subsequently 
request  the  database  record  in  position  7,  by  issuing 
a  Present  request  in  which  that  record  is  the  only 
record  requested. 
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Note  that  the  purpose  of  this  distinction  between 
Preferred-message-sizfi  and  Maximum-record-size  is 
to  allow  the  transfer  of  normal  length  records  to 
proceed  in  a  routine  fashion,  with  convenient  buffer 
sizes,  but  to  also  provide  for  the  transfer  of  an 
occasional  exceptionally  large  database  record  without 
requiring  the  origin  to  continually  allocate  and  hold 
local  buffer  space  for  worst-case  records.  Note  also 
that  this  intended  purpose  is  defeated  if  the  origin 
routinely  requests  a  single  record. 


3.4  Reference-id 

The  parameter  Reference-id  is  optional  in  an  Init, 
Search,  Present,  Delete,  and  Resource-report  request. 
•  If  supplied, 

it  must  be  echoed  by  the  target  in  die  respec- 
tive response; 

it  must  be  echoed  in  both  the  request  and 
response  of  any  intermediate  Access-control  or 
Resource-control  request/response  sequences; 
and 

it  must  be  echoed  by  the  origin  in  any  inter- 
mediate Trigger-resource-control  request. 
If  Reference-id  is  not  supplied  in  an  Init,  Search', 
Present,  Delete,  or  Resource-report  request,  then  it  is 
not  to  appear  in  the  respective  response,  nor  in  either 
the  request  or  response  of  any  intermediate  Access- 
control  or  Resource-control  request/  response  se- 
quence, nor  in  any  intermediate  Trigger-resource- 
control  request. 

The  service  does  not  assume  any  relationship 
between  the  Reference-id  used  in  an  Init,  Search, 
Present,  Delete,  or  Resource-report  request  and  the 
Reference-id  used  in  any  other  Init,  Search,  Present, 
Delete,  or  Resource-report  request. 

The  purpose  of  this  parameter  is  to  facilitate  the 
grouping  of  events  by  the  origin  system.  This  stan- 
dard does  not  specify  its  contents.  Reference-ids  are 
always  assigned  by  the  origin  and  have  meaning  only 
within  the  origin  system.  Since  there  are  no  seman- 
tics attributed  to  this  parameter,  it  has  no  implied 
datatype  and  can  only  be  described  as  transparent 
binary  data.  It  is  therefore  described  as  ASN.l  type 
OCTETSTRING. 


4,  Protocol  Specification 

This  version  of  the  ANSI  Z39.5Q-1992  Informa- 
tion Retrieval  protocol  is  version  2. 

Note:  For  the  purpose  of  interworking  with 
version  1  of  the  Search  and  Retrieve  Protocol 
(ISO  10163),  Version  2  of  Z39.50  is  assumed 
identical  to  version  1  of  Z39.50;  thus  imple- 
mentations which  support  version  2  automati- 
cally support  version  1.  Implementations  that 
intend  to  interwork  with  SR  implementations 
as   well   as   other   Z39.SO  implementations 
should  indicate  support  for  both  versions  1 
and  2  (Version   1   of  ANSI  Z39.50-1992 
should  not  be  confused  with  ANSI  Z39.50- 
1988). 
The  Information  Retrieval  application  protocol 
specifies  the  formats  and   procedures  governing  the 
transfer  of  information  between  peer  information 
retrieval  applications.  A  unit  of  information,  passed 
between  two  peer  applications  is  called  an  "applica- 
tion protocol  data  unit"  or  APDU. 

4.1    Abstract  Syntax  of  the  Information 
Retrieval  Protocol 

The  Information  Retrieval  protocol  data  units  are 
complex  data  types.  The  transfer  syntax  of  these  data 
types  is  negotiated  by  the  presentation  service 
provider.  The  definitions  in  this  section  specify  the 
component  data  elements  of  the  protocol  data  units 
and  the  Type-1  query. 

4.1.1  ASN.l  Specification  of  the  APDUs 

This  section  describes  the  abstract  syntax  of  the 
Z39.50  APDUs,  using  die  ASN.l  notation  defined  in 
ISO  8824.  The  comments  included  within  the  ASN.  1 
specification  constitute  part  of  the  standard. 
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IR  DEFINITIONS  ::  = 

BEGIN    -  ANSI  Z39.S0  version  2-Jufy  1, 

PDU  :;=  CHOICE{ 
initRequest 
initResponse 
searchRequest 
searchResponse 
presentRequest 
presentResponse 
deleteResultSetRequest 
deleteResuItSetResponse 
accessControIRequest 
accessControlResponse 
resourceControlRequest 
resourceControIResponse 
triggerResourceControlRequest 

resourceReportRequest 
resourceReportResponse 

--  new  APDUs  can  be  added  m  the 
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[20] 

IMPLICIT 

[21] 

IMPLICIT 

[22] 

IMPLICIT 

[23] 

IMPLICIT 

[24] 

IMPLICIT 

[25] 

IMPLICIT 

[26] 

IMPLICIT 

[27] 

IMPLICIT 

[28] 

IMPLICIT 

[29] 

IMPLICIT 

[30] 

IMPLICIT 

[31] 

IMPLICIT 

[32] 

IMPLICIT 

[33] 

IMPLICIT 

[34] 

IMPLICIT 

future  at  the  end  of  this  tist 

InitialkeRequest, 

InitializeResponse, 

SearchRequest, 

SearchResponse, 

PresentRequest, 

PresentResponse, 

DeleteResultSetRequest, 

DeleteResuItSetResponse, 

AccessControIRequest, 

AccessControlResponse, 

ResourceControlRequest, 

ResourceControIResponse, 

TriggerResourceControlRequest, 

ResourceReportRequest, 

ResourceReportResponse} 


InitializeRequest  ::=sequence{ 

referenceld  Referenceld  OPTIONAL, 

protocoTVersion  ProtocoIVerston, 

-  proposed  version  of  the  protocol  to  be  used  (see  below).    ( 
options  Options, 

-  proposed  set  of  services  to  be  used 
preferredMessageSke  PreferredMessageSta, 

--  origin  proposal  for  the  size  of  large  messages  (where  message  size  is 

-  the  sum  of  sizes,  in  bytes,  of  the  records  in  an  APDU)  the  target 

-  should  normally  use  when  presenting  groups  of  records;  however,  the 
~  fust  record  in  a  response  is  permitted  to  cause  the  message  to 

-  exceed  this  size  (see  also  maamumRecordSize  below). 
maximumRecordShe  MadmumRecordSiM, 

-  origin  proposal  for  maximum  record  size  (number  of  bytes). 

-  Value  must  be  greater  than  or  equal  to 

-  preferredMessageSize. 

IdAuthenticatJon  [7]   ANY  OPTIONAL, 

--  information  as  required  by  the  target  to  access  the 

-  responding  IRPM;  syntax  of  this  parameter  to  be 

-  defined  by  the  target  prior  to  communication. 
Implementatloold  Implementationld  OPTIONAL, 
ImpIementationNanM  ImpkmentationNam®  OPTIONAL, 
impleinentationVersIon  ImpJeajentaifooVersion  OPTIONAL, 
userlMormationFseld  UserlnforamtionF^M  OPTIONAL} 

InitializeResponse  ««  sequence{ 

referenceld  Referenceld  OPTIONAL, 

protocoTVersion  ProtocoTVeraion, 

options  Options, 

preferredMessageSize  PrefemdMeMageSuoe, 

-  target  decision  on  maximum  APDU  size  (see  description  under 
..  InitiakzationRequest  definition).  Value  is  allowed  to  be  different 

-  from  what  origin  proposed  in  the  Initialization  Request;  if  origin 

-  does  not  agree  on  target  values,  U  may  abort  the  connection. 
-  (InitializeResponse  continued  next  page) 
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■  (MtiaUzeResponse   continued) 

maximumRecordSize  MaximumRecorclSize, 

-  target  decision  on  tfte  mwdmum  record  me 

result  [12]   IMPLICIT  BOOLEAN, 

-  result  of  the  processing  of  the  request  at  the  tmget 

-  reject  -  FALSE;  Accept  -  TRUE 

Implementationld  .  ImpJemeotaiionM  OPTIONAL,, 
ImpIementatiQnNaiiie  ImpJemeotaiionNaiiie  OPTIONAL, 

ImpIeroentatioaVerricm  ImplemeniaiMnVerskM  OPTIONAL, 

userlnformaftmFrfd  UserlnfonnaiicmFIeM  OPTIONAL} 

■  Auxiliary  definitions  for  Initialization  APDUs 

ProtoarfVersJon  s=    [3]    IMPLICIT  BIT  STUNG 

-  represents  a  string  of  Boolean  values,  each  value  representing 

-  a  version.  The  first  vahte  set  to  1  indicates  version  I  k  avaUabk, 

-  the  second  value  set  to  1  indicates  version  2  is  available,  md$oon. 

-  Values  higher  than  the  highest  known  version  should  be  ig%ored.  Both  the 

-  Initialize  and  Initialize  Response  APDUs  include  a  vahte  string 

-  corresponding  to  the  supported  versions.  The  Mutest  common  version  is 

-  selected  for  use.   If  there  are  no  versions  in  common,  the  Initialize 

-  Response  APDU  should  indicate  a  value  of  "rejecf  for  the  parameter 

-  Result  Note:  Versions  land  2  are  idendcaL  Systems  supporting 

-  version  2  should  indicate  support  for  version  1  as  wett, 

-  for  interoperability  with  systems  that  indicate  support  for 

-  version  1  only  (e.g  ISO  10163  implementations). 
Options  s=    [4]  IMPLICIT  BIT  STRING 

{search  (0), 

present  ''  (1), 

ddSet  (2), 

resourceReport  (3), 

triggerResoareeCtri     (4), 
resmirceCtrl  (5), 

sccessCtri  (£)} 

-  In  InitializeRequest,   for  bits  0  through  4,  ON  indicates  mutator  does 

-  request  use  of  service;  for  bits  5  and  6,  ON  indicates  initiator  wUl 

-  support  service  For  MtiaUzeResponse,  for  bit  0  through  4,  ON  indicates 

-  target  will  support  service;   for  bits  5  and  6,  ON  indicates  target  requests 

-  service  For  extensibility  of  the  protocol,  additional  bits  set  should 
-not  be  considered  to  he  an  error  on  received  InitializeRequest 

PrefermlMessageSize        n=     [5]  IMPLICIT  INTEGER 

MaximumRecordSte         a=     [6]  IMPLICIT  INTEGER 

Implementaiionld  n=   [110]         IMPLICIT  YlsIMeSfring 

-  a  unique  identifier  for  the  origin  or  target  implementation 
ImplementatlooName         s=    [111]  IMPLICIT  VMMeSiring 

~  a  descriptive  name  for  the  origin  or  target  bnplementation 
ImplementaiJonVersfon      a«    [112]  IMPLICIT  VbfldeString 

-  descriptive  name  for  the  origin  or  target  impL  version 

-  these  three  implementation  parameters  are  provided  solely  for 

-  the  convenience  of  implementors  needing  to  distinguish  impkmen- 

-  tations.  They  shall  not  be  the  subject  of  conformance  tests. 

UserlnfanrntkraFseM         a=    [11]     EXTERNAL 

-  additional  information,  not  defined  in  this  standard 
-  end  auxiliary  definitions  for  initialization  APDUs 
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SearchRequest  ;:=  sequence{ 

rdTerenceld  RrffapmceM  ©PHONAL, 

iimallSeiUpperBound  [13]   IMPLICIT  INTEGER, 

-if  the  number  of  hits  is  less  than  or  equal  to  Ms  number,  all  ncenh  me 

-  to  be  returned  in  the  SearchResponse   (within  the  Umits  pvm  by  the 

-  negotiated  preferred-McssageSue    and  mwdmumRecordSize),  composed  as 

-  specified  by  the  smaUSetEkmentSetNames  parameter  below.  May  be  aero. 
EargeSetLcmerBouiMi  [14]   IMPLICIT  INTEGER, 

-  if  the  number  of  hits  is  equal  to  or  fftoter  than  this  number,  no  records  me 

-  to  be  returned  LargeSetLowerBound  must  be  grater  than  smaUSetUpperBound. 
roediumSetPresentNumlw        [15]   IMPLICIT  INTEGER, 

-  maximum  number  records  to  be  returned  in  the  SearchResponse  if&e  number 

-  of  hits  «  between  largeSetLowerBound  and  smaUSetUpperBound   (again 

-  within  the  Umits  given  by  PreferredMessageSue    and  MaxtmumRecordStte), 

-  composed  as  specified  by  nuidhtmSetRecordEkmentSetNames 
replacelndicator  [16]   IMPLICIT  BOOLEAN, 

-  origin  indicates  whether  or  not  to  replace  a  previously  created  result 

-  set  with  the  same  name  by  the  one  that  is  constructed  in  this  March 
resultSeiName  [17]   IMPLICIT  VisibleString, 

-  origin  proposal  for  naming  of  the  result  set  that  w  constructed  if  hits 

-  are  found  If  target  allows  the  origin  to  assign  names  to  result  sets, 

~  it  uses  this  proposed  name.  If  the  target  does  not  support  named  result 

-  sets,  it  returns  an  error  diagnostic 

databaseNames  [18]  IMPLICIT  SEQUENCE  OF  BaiabaseNsiiie, 

-  database(s)  in  which  the  search  will  be  performed 
smallSetElementSetNames         [100]  IMPLICIT  EfementSetNames  OPTIONAL, 

-  origin  proposal  for  composition  of  the  records  m  the  mnaU 

-  set  (see  above  under  smaUSetUpperBouHd).  

mediumSetElementSetNames     [101]  IMPLICIT  EfementSetNames  OPTIONAL, 

-  origin  proposal  for  the  composition  of  the  records  in  the 

-  medium  set  (see  above  under  mediumSetPresentNumber). 

preferredRecordSyntax  PreferredRecordSyntax  OPTIONAL, 

--  origin  proposal  for  abstract  syntax  of  the  database  records  to  be  returned 

-  in  the  SearchResponse.    Values  subject  to  registration. 
query  [21]       Quay} 

-  the  search  argument  (see  description  below). 

Query  ::=    CHOICE 

{type-0  [0]  ANY, 

type-1  [1]  IMPLICIT  RPNQwsy, 

type-2  [2]  OCTET  STRING, 

type-100  [100]  OCTET  STRING, 

type-101  [101]  IMPLICIT  OCTET  STRING} 

-  the  search  argument  contained  in  the  SearchRequest     Five  types  are  defined: 

-  a)       A  type-0  quay  may  be  used  only  when  the  origm  and  target  have  an  a  priori 

-  agreement  outside  of  Ms  standard  as  to  form  of  query  acceptable  to  target. 

-  b)  type-1  is  the  Reverse  Polish  Notation  (RPN)  query  (see  below). 

-  e)  type-2  is  the  1S08777  type  query,  specified  in  ISO  8777. 

-  d)  type-100  is  the  Z39.5S  type  query,  specified  in  ANSI  Z39.S& 
~  e)  type-101  is  the  proximity  query,  specified  in  Appendix  G. 

RPNQuery  ::«   SEQUENCE{ 

sttributeSetld  OBJECT  IDENTIFIER,  -  identifies  attribute  set 
RPNStructure} 


21 


RPNStrociure  a*  CHOICE  {  [0]  Operand, 

[1]  IMPLICIT  SEQUENCE  { 
RrNStnucture, 
RPNStroctnre, 
Operator}} 

Operas  s=  CHOICE{ 

ResultSeild} 
AttributesHusTotTOJ=    [102]  IMPLICIT  SEQUENCE{ 

AttributdUit, 

Tom} 
Attributelist     s=    {44}   IMPLICIT  SEQUENCE  OF  AitritateEtaniaQi 
Term  s=    [45]    IMPLICIT  OCTET  STRING 

-  the  type  OCTET  STRING  is  used  to  enable  the  inclusion  ofmuMbyte 

-  character  representations   which  the  types  CharacterString  and 

-  VmbleString  might  impose  on  graphic  character  repertoire. 
Operator  a=    [46]     CHOICE{ 

and  [0]  IMPLICIT  NULL, 

or  [1]  IMPLICIT  NULL, 

and-not  [2]  IMPLICIT  NULL} 

AttributeBement  a=   SEQUENCE{ 
Attributeiype, 
AtiributeValue} 
AttributeType  a=    [120]  IMPLICIT  INTEGER 
AttributeValu®  a=    [121]  IMPLICIT  INTEGER 
-AttributeType    and  AttributeValue   interpretation  is  governed  by  the 

-  values  contained  in  the  definition  identified  by  AttributeSetld 

SearchResponse  ::=  sequence{ 

refereaceld  Referenceld  OPTIONAL, 

resultCount  [23]   IMPLICIT  INTEGER, 

-  number  of  hits  resulting  from  the  search. 
numterOCRecordsRetunied  NumbarOmeawdsRetnnKd, 

-  number  of  records  in  the  search  results  below. 
nextResuItSetPositkm  r  NeiriResultSetPosiiion, 

--  the  ordinal  number  in  the  result  set  of  the  record  appearing  directly 

-  after  the  last  record  in  the  search  Results  below.  

geardiStaius  [22]  IMPLICIT  BOOLEAN, 

-  result  of  the  processing  of  the  request  at  the  target  IRPM. 

-  success  =  TRUE;  failure  =  FALSE. 

resultSetStatas  [26]   IMPLICIT  INTEGER{ 

rabxt  (1), 

faiterim  (2), 

now!  (3)}    OPTIONAL, 

-  occurs  if  and  only  if  search-status  is  FALSE.  Indicates  the 

-  presence  and  validity  of  the  result  set  produced. 

presentStatus  PreseniSiatus  OPTIONAL, 

-  occurs  if  and  only  if  search-status  is  TRUE  Indicates 

-  presence  and  validity  of  records  appearing  in  the  search  results 
databaseOrDiagnosticReconls  Records  OPTIONAL} 

--  the  records  (diagnostic  and/or  bibliographic)  resulting 

-  from  the  search  (see  description  below). 
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PresentRequest  ;:=  sequence{ 

rtfereaceld  Referroceld  OPTIONAL, 

residtSettd  Result&iH, 

-  identification  of  the  remit  se?  from  which  to  reuieve  records 
resultSetStartPoint  [30]      IMPLICIT  INTEGER, 

-  ordinal  number  in  the  result  set  of  the  first  record  to 

-  appear  in  the  present  results  in  the  PresentRespomc 
numberOmecordsRequested  [29]      IMPLICIT  INTEGER, 

-  specifies  the  maximum  number  of  records  to  be  returned  in  the  present 

-  results  in  the  PrtsentRcsponse    (within  the  limits  gven  by  the 

-  negotiated  message  and  record  me  parameters),  composed  as  specified 

-  by  the  element  set  names  parameter  below. 
BementSetNameii  OPTIONAL* 

-  origin  proposal  for  the  composition  of  the  records  to  be 
~  returned  in  the  in  the  Present  Response 

^eferredRecordSyntm  PrrfmwIRecordSyntitt  OPTIONAL} 

-  origin  proposal  for  abstract  syntax  of  the  database  records  to  be  returned 
-in  the  present  results  in  the  Present  Response.    Values  subject 

-  to  registration,   at  present  by  specification  in  Appendix  E. 

PresentResponse  ::=  sequence{ 

referenceld  Referenced  OPTIONAL, 

numberOntecordsRetumed  NumberOCRecordsReturned, 

-  number  of  records  returned  in  the  records  parameter  below. 
nextResultSetPositkm  NerfResultSeffosition, 

-  ordinal  number  in  the  result  set  of  the  record 

-  appearing  directly  after  the  last  record  returned 
presentStaius  PresentStafaw, 

-  indicates  the  presence  and  validity  of  the  records 
claiabaseOrDmgnostkReconls  Records  OPTIONAL}  -  the  presented  records 

■  begin  auxiliary  definitions  for  search  and  present  APDUs 
Records  ::=  CHOICE{ 

dataBaseOrSurDiagnostks        [28]   IMPLICIT  SEQUENCE  OF  NsuMPlosRecori, 
nooSurrogateDiagBostk  [130]  IMPLICIT  DiagRec} 

NameHusRecorf  s=   SEQUENCE{ 

[0]  IMPLICIT  DatabaseName  OPTIONAL, 
-presence  of  DatabaseName  is  conditional  See  3.2Z1.7  and  3.Z3.1.S. 
[1]  CHOICE{  daiabaseReconi  [1]  DatabaseRecori, 

surrogateDlagnostfc       [2]  DiagRec}} 

DatabaseReconI  s«   EXTERNAL 

-  the  database  record  syntax  is  defined  outside  of  this  standard 

-  For  bibliographic  data,  USMARC  «  a  prime  example. 

DiagRec  s=   SEQUENCE{ 

diagnostkSetld  OBJECT  IDENTIFIER, 

condition  INTEGER, 

-interpretation  of  condition  is  governed  by  values 

-  contained  in  definition  identified  by  DiagnosticSald 
addinfo  YisiWeSWiig}  -  uMl  information. 
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BementSetNames  ;:=    [19]     CHOICE{ 

generic  [0]  IMPLICIT  BeroeoiSetNimie, 

databaseSpecifie    [1]  IMPLICIT  SEQUENCE  OF  SEQUENCE! 

DatabaseNaine, 

DementSetNiiiiie}} 

ESemefltSdNamg  s-    [103]    IMPLICIT  VuabfeStriiig 

-  A  target  must  always  recognize  the  value  "F"  to  mem  *fuU  record". 

-  begin  miscellaneous  definitions  for  starch  mtd  present  APDUs 

NumberOfReeordsReturned  ss=    [24]    IMPLICIT  INTEGER 

NextResultSetPosittom  s=    [25]    IMPLICIT  INTEGER 

PresentStatus  a=    [27]    IMPLICIT  MTEGER{ 

mcasi  (0), 

fBTtM-l  (1), 

partnl-2  (2), 

partiaW  (3), 

partiuM  (4), 

failure  (f)} 
PreferredRecordSyntax           s=    [104]     IMPLICIT  OBJECT  IDENTIFIER 

-  em*  miscellaneous  definitions  for  search  and  present  APDUs 

-  end  auxiliary  definitions  for  search  and  present  APDUs 

DeleteResuItSetRequest  ::=sequence{ 

referenced  Referenceld  OPTIONAL, 

deleteOperation  [32]   IMPLICIT  INTEGER{ 

list      (0), 

aB         (1)}, 

resultSetlist  SEQUENCE  OF  ResultSettd  OPTIONAL  } 

-  identification  of  result  sets  to  be  deleted  if  operation  is  "Usf 

DeleteResultSetResponse  ::=  sequence! 

refereoceld  Referenceld  OPTIONAL, 

deleteOperationStatus  [0]   IMPLICIT  DefeteSetStaius, 

--  Reports  status  for  entire  delete  operation.    Values  limited  to 

-  "success"  or  "failure-3"  through  "failure-9".  Values  of  "faUure-T 
--  and  "failure-8"  may  be  used  only  if  operation  b  "alT. 

deletelistStatuses  [1]   IMPLICIT  OstStotuses  OPTIONAL, 

-  Must  occur  if  operation  is  "list".   Individual  status 

-  values  limited  to  "success"  through  failures', 
numberNoiDeteted  [34]  IMPLICIT  INTEGER  OPTIONAL* 

-  No.  sets  target  failed  to  delete.  Occurs  only  if  operation  is  "aW. 

buIkStatuseii  [35]  IMPLICIT  LJstStatuses  OPTIONAL, 

-  occurs  if  and  only  if  DeleteSetStatus   equals  8.  Individual 

-  statuses  limited  to  "success"  through  "faUure-6" 

ddeteMessage  [36]      IMPLICIT  YisiWeString  OPTIONAL} 

-  textual  message  concerning  the  delete  operation. 

-  begin  auxiliary  definitions  for  delete 

LtstStatuses  a=  SEQUENCE  OF  SEQUENCE! 
ResultSetld, 

DekteSetStetus} 
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BdeteSetStatus  a=  [33]  IMPLICIT  INTEG»{ 

guecess  (0)» 

resulSetDidNot&M  (l%> 

previousIyDddMByrar^  (2), 

/     gystemProbtemACTa]^  (3), 

accessNoiAIkiwwI  (4), 

resoor^CcmtnJAIOrigln  (5), 

resourceCoofaPidAtTargrt  (6), 

tMilkDeMi^atSupportei  (7), 

mrtAIlRsltSetsD^iedOnBiiIkDlte  (i), 

notAURequest^Result^D^Arf  (9)} 
-7  and  8  used  onfy  if  operation  is  "eW. 
■  eru/  awdtiary  definitions  for  delete 

AccessControIRequest ::-  sequence{ 

refereoeeld  Referencsld  OPTIONAL, 

BecurityOwHenge  [37]  Seamtyftyrmiiieter} 

AccessControIResponse  v.=  sequence{ 

refereaceld  Refereoeeld  OPTIONAL, 

gecurityOialleiigeResponse        [38]  SeamtyPmranieter} 

-  begin  auxiliary  definitions  for  Access  Control 

SecurityParameter  zt-  CHOICE{ 

oWway  IMPLICIT  OCTET  STRING, 

-  for  1988  compatibility 
newway  EXTERNAL} 

-  end  auxiliary  definitions  for  Access  Control 

ResourceControIRequest  ::=  sequence{ 

referenceld  Refereoeeld  OPTIONAL, 

tsuspendedFlag  [39]  IMPLICIT  BOOLEAN  OPTIONAL, 

-  nou€n  —  suspended 

resourceRerort  [40]  ResoarceReport  OPTIONAL, 

I»rtialResultsArailabIe  [41]  IMPLICIT  INTEGER{ 

subset  (1), 

interim  (2), 

none  (3)}  OPTIONAL, 

responseRequiral  [42]  IMPLICIT  BOOLEAN, 

-•  "true"  means  that  the  target  requires  a  response  

triggeredRequestFla§  [43]  IMPLICIT  BOOLEAN  OPTIONAL} 

-  "true"  means  request  triggered  by  a  trigger-resourte-eontrol    request 

ResourceControIResponse  «=  sequence{ 

referenedd  Refereoeeld  OPTIONAL, 

omtuiueFlfie  [44]  IMPLICIT  BOOLEAN,  -  me  -  eamkme 

resultSetWanted  [45]  IMPLICIT  BOOLEAN  OPTIONAL} 

_  "jf^j"  b  "result  set  wanted",  required  during  a  March  if 

-  Continue  flag  is  false;  otherwise  should  not  occur 


25 


TriggerResourceControIRequest  «=  sequence{ 

referenceld  Rdermceld  OPTIONAL, 

rf^uestedOperafion  [4§]  IMPLICIT  INTEGER{ 

resoureeReport  (1), 

resouroeCmatai  (2),  \ 

amcd  (3)},  X 

ptfenredResourceReportFoniiat  [47]  IMPLICIT  RmareeR^orttd  OPTIONAL, 

resultSetWaiital  [48]  IMPUCIT  BOOLEAN  ©PHONAL} 

ResourceReportRequest  ::■  sequence{ 

rrfereoceld  MefereaagM  OPTIONAL, 

p^erredResouroiReportF onnai  [49]  IMPLICIT  ResouraJteportM  OPTIONAL} 


ResourceReportResponse  »- 

SEQUENCE{ 

refereoceld 

RefereoaJd  OPTIONAL, 

resourceReportSiaius 

[50]  IMPLICIT  INTEGERC 

SSICOgSi 

(0), 

partial 

(1), 

bUure-i 

(2), 

MIure-2 

(3), 

firiIure-3 

(4), 

feilure-4 

(5)}, 

resoureeReport  '  [51]  ResoureeReport  OPTIONAL} 


-  Begin  auxiliary  definitions  for  resource  control 

ResoureeReport  s=  EXTERNAL 
ResourceReportld  s=   OBJECT  IDENTIFIER 

-  End  auxiliary  definitions  for  resource  control 

begin  global  auxiliary  definitions 

Refereoceld  s=    [2]     IMPLICIT  OCTET  STRING 

-  value  provided  by  the  service  originator  in  the  Request  APDU,  target 

-  required  to  send  it  back  unaltered  in  corresponding  response  APDU 
DatabaseName  s=    [105]  IMPLICIT  TisiWeSiring 
ResultSetld  s=    [31]   IMPLICIT  TisibleSirin^ 

-  end  global  auxiliary  definitions 

END-m 
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4*2  Protocol  Procedures 

This  section  specifies  services  required  by  die 
protocol,  the  protocol  model,  state  tables,  handling  of 
protocol  errors,  rules  for  extensibility,  and  confor- 
mance requirements. 

4.2.1  Services  Required 

The  Information  Retrieval  protocol  assumes 
service  from  the  Presentation  layer  and  the  associa- 
tion  control  service  element. 

4.2.1.1  Service  Required  from  the 
Presentation  layer 

The  protocol  uses  the  presentation  service  as 
.defined  in  ISO  8822  to  provide  a  presentation  connec- 
tion for  communication  between  two  information  re- 
trieval applications.  The  presentation  services  re- 
quired are  those  contained  in  the  presentation  kernel 
functional  unit  and  the  session  duplex  functional  unit. 
The  association  control  service  element  may  have 
additional  requirements  for  presentation  services. 

All  Information  Retrieval  protocol  data  units  will 
be  mapped  onto  the  P-Data  service.  The  communica- 
tion service  that  supports  this  protocol  is  a  connec- 
tion-oriented service  using  the  P-DATA  service,  de- 
fined in  ISO  8822  in  an  established  application  asso- 
ciation, in  combination  with  the  ACSE,  ISO  8649. 

A  Z39.50  origin  establishes  application-associa- 
tions as  necessary  with  the  target  with  whom  it  is 
engaged  in  Z39.50  activity.  The  Z39.50  application- 
service-element  (ASE)  may  then  use  the  P-DATA 
service  defined  in  ISO  8822  directly  to  transmit 
Z39.50  APDUs.  This  provides  a  connection-oriented 
interaction  between  Z39.50  systems.  A  single  appli- 
cation-association can  be  used  to  send  a  series  of 
Z39.50  APDUs  relating  to  multiple  searches.  A 
single  system  can  be  engaged  in  multiple  application 
associations  with  multiple  remote  systems  simulta- 
neously. 

4.2.1.2  Association  Control  Services 

Assumed 

The  protocol  assumes  the  services  of  the  associa- 
tion control  service  elements  as  defined  in  ISO  8649. 
The  services  required  are: 

1)  orderly  association  release,  where  both  sides 
agree  to  the  release  and  there  is  no  loss  of 
data  in  transit  (the  IR-release  service  is  direct- 
ly mapped  to  this  service  without  any  Infor- 
mation Retrieval  protocol  control  informa- 
tion), and 


2)    association  abort,  which  allows  either  origin 
or  target,  at  any  time,  to  explicitly  terminate 
the  association,  immediately  and  uncondition- 
ally. Data  in  transit  may  be  lost  (the  IR-abort 
service  is  directly  mapped  to  this  service 
without  any  Information  Retrieval  protocol 
control  information). 
It  is  assumed  that  prior  to  APDUs  being  ex- 
changed the  Information  Retrieval  service  user  will 
handle  the  association  control  services  required  to 
establish  an  association  with  an  application  context 
encompassing  the  Information  Retrieval  service.  The 
application  context  °basic-Z39.50-ac"  is  registered  in 
appendix  A  and  defined  Appendix  B. 

4X2  Protocol  Model 

To  specify  protocol  procedure,  the  abstract, 
implementation-independent  concepts  of  service-user, 
service-provider,  and  service  primitive  are  used. 

A  service-provider  provides  a  communication  path 
between  two  service  users.  A  service  primitive  is  an 
element  of  interaction  between  the  service-user  and 
the  service-provider.  There  are  four  types  of  service 
primitives:  Request,  Indication,  Response  and  Confir- 
mation. For  a  confirmed  service  initiated  by  the 
origin  (i.e.,  for  Z39.50:  Search,  Present,  Delete,  and 
Resource-report)  they  are  used  as  follows: 

1)  Request  -  A  primitive  issued  by  the  origin 
service-user  to  the  service-provider  in  order  to 
invoke  some  procedure. 

2)  Indication  -  A  primitive  issued  by  the  service- 
provider  to  the  target  service-user  to  indicate 
that  a  procedure  has  been  invoked  by  its  peer. 

3)  Response  -  A  primitive  issued  by  the 
target  service-user  to  the  service-provider  at 
the  completion  of  the  procedure  previously 
invoked  by  an  indication. 

4)  Confirmation  -  A  primitive  issued  by  the 
service-provider  to  the  origin  service-user,  to 
complete  the  procedure  previously  invoked  by 
a  request. 

Notes: 

(1)  For  a  confirmed  service  initiated  by  the  target 
(i.e.,  for  Z39.50:  Access-control  and  Re- 
source-control) me  roles  of  origin  and  target 
are  reversed. 

(2)  For  a  non-confirmed  service  (i.e.,  for  Z39.50: 
Trigger-resource-control)  only  the  Request  and 
Indication  primitives  are  used. 

Primitives  are  conceptual  and  their  use  neither 
specifies  nor  precludes  any  specific  implementation 
of  a  service.     Only  primitives  that  correspond  to 
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some  element  of  the  service  involving  the  exchange 
of  information  between  systems  are  defined. 

From  the  perspective  of  the  service-diser,  the 
service-provider  is  system-independent.  For  the 
exchange  of  protocol  however,  a  distinction  is  made 
between  those  portions  of  the  service-provider  resid- 
ing on  the  origin  and  target  systems  (respectively, 
fee  origin  service-provider  and  the  target  service- 
provider).  See  figure  1.  The  sequence  of  interactions 
for  a  confirmed  service  initiated  by  the  origin  is: 

1)  Request  Primitive  from  origin  service-user  to 
service-provider. 

2)  Protocol  Message  from  origin  service-provider 
to  target  service-provider. 

3)  Indication  Primitive  from  service-provider  to 
target  service-user. 

4)  Response  Primitive  from  target  service-user  to 
service-provider. 

5)  Protocol  Message  from  target  service-provider 
to  origin  service-provider. 

6)  Confirmation  Primitive  from  service-provider 
to  origin  service-user. 


Notes: 

(1)  For  a  confirmed  service  initiated  by  the 
target,  the  roles  of  origin  and  target  are 
reversed. 

(2)  For  a  non-confirmed  service,  only  steps  1 
.     through  3  apply. 

The  following  illustrates  the  sequence  of  interac- 
tions which  occur  for  a  Search  operation: 

1)  Search  request  from  origin  service-user  to 
service-provider. 

2)  Search  APDU  (Application  Protocol  Data 
Unit)  from  origin  service-provider  to  target 
service-provider. 

3)  Search  indication  from  service-provider  to 
target  service-user. 

4)  Search  response  from  target  service-user  to 
service-provider. 

5)  Search-response  APDU  from  target  service- 
provider  to  origin  service-provider. 

6)  Search  confirm  from  service-provider  to 
origin  service-user. 


Figure  1  -  Sequence  of  Interactions 
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Note:  The  interfaces  between  service  user  and  service 
provider,  as  represented  by  steps  1  and  6  for  the 
origin,  and  by  steps  3  and  4  for  the  target,  are 
described  solely  to  facilitate  the  specification  of 
protocols.  These  steps  do  not  represent  intersystem 
communication,  and  therefore,  the  means  by  which 
they  are  implemented  are  not  constrained  by  this 
specification.  In  an  actual  implementation,  step  4, 
for  example,  might  consist  of  several  messages  from 


the  target  service  user  to  service  provider.  On  the 
other  hand,  both  the  target  service  user  and  service 
provider  could  be  combined  in  a  single  program,  in 
which  case  steps  3  and  4  might  not  have  any  real 
physical  manifestation. 

4.23  State  Tables 

This  section  defines  two  Information  Retrieval 
Protocol  Machines  (IRPMs)  in  terms  of  state  tables. 
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One  state  table  is  defined  for  the  origin  (table  10)  and 
one  state  table  is  defined  for  the  target  (table  11). 
Each  state  table  shows  the  inter-relationship  between 
the  state  of  an  Information  Retrieval  association,  the 
incoming  events  that  occur  in  the  protocol,  the 
actions  taken,  and,  finally,  the  resulting  state  of  the 
association.  The  IRPM  state  table  does  not  constitute 
a  formal  definition  of  the  IRPM.  It  is  included  to 
provide  a  more  precise  specification  of  the  protocol 
procedures.  The  following  conventions  are  used  in 
the  state  tables. 

State  Table  Cells  The  intersection  of  an  incoming 
event  (row)  and  a  state  (column)  forms  a  cell.  A 
blank  cell  represents  the  combination  of  an  incoming 
•  event  and  a  state  that  is  not  defined  for  the  IRPM.  A 
non  blank  cell  represents  an  incoming  event  and  state 
that  is  defined  for  the  IRPM.  Such  a  cell  contains 
one  or  more  actions,  separated  by  semi-colons  (;). 

Actions  to  be  Taken  by  the  IRPM  The  IRPM  state 
tables  define  the  action  to  be  taken  by  the  IRPM  in 
terms  of  one  or  more  outgoing  events  (separated  by 
semi-colons)  and  the  resulting  state  (in  parenthesis)  of 
the  Information  Retrieval  association. 


Invalid  Intersections  Blank  cells  indicate  an  invalid 
intersection  of  an  incoming  event  and  state.  The  state 
tables  define  correct  operation  only.  They  do  not 
specify  actions  to  be  taken  in  response  to  incorrect 
operation  (for  example,  erroneous  protocol  control 
information,  incorrect  protocol  control  actions,  etc.). 
Such  actions  are  not  within  the  scope  of  the  specifica- 
tion, although  implementations  must  consider  mem. 

4*2,4  Protocol  Errors 

Any  events  not  listed  in  the  tables  of  section  4.2.3 
are  not  valid  and  are  considered  to  be  protocol 
errors.  With  exceptions  specified  in  section  4.3, 
incorrectly  formatted  APDUs  or  APDU's  with  invalid 
data  are  also  considered  to  be  protocol  errors.  This 
standard  does  not  specify  the  actions  to  be  taken  upon 
detection  of  protocol  errors.  An  application  context 
may  contain  such  a  specification. 

43  Rules  for  Extensibility 

All  syntactical  errors  in  received  APDUs  are 
considered  to  be  protocol  errors  except  for  the 
following  case:  Unknown  data  elements,  and  un- 
known options  within  the  Options  data  element,  will 
be  ignored  on  received  Init  APDUs. 


Table  8:  Definition  of  Smut 

Origin  States 

Target  States 

No, 

Name 

Description 

No, 

Name 

Description 

1 

Closed 

the  origin  ia  awaiting  an  Init  request 
from  the  application 

1 

Closed 

the  target  is  awaiting  an  Init 
APDU 

2 

Init  sent 

the  origin  has  transmitted  an  Init 
APDU  to  the  target 

2 

Iratrecvd 

toe  target  has  issued  an  Init 
indication 

3 

Open 

the  origin  i«  awaiting  a  Search, 
Present,  Delete,  or  Resource-report 
request 

3 

Open 

the  target  is  awaiting  a  Search, 
Present,  Delete,  or  Resource-report 
APDU 

4 

Search  Salt 

the  origin  hai  transmitted  a  Search 

4 

Search 

the  target  has  issued  a  Search 

APDU 

r@c?d 

indication 

5 

Prait  seat 

the  origin  has  transmitted  a  Present 
APDU 

5 

Prsat  r©c?d 

the  target  has  issued  a  Present 
indication 

6 

Delete  seat 

the  origin  has  transmitted  a  Delete 
APDU 

€ 

Dfieterecvd 

the  target  has  issued  a  Delete 
indication 

7 

Rsrpsent 

the  origin  hat  transmitted  a  Re- 
source-report APDU 

7 

RsrpRec?d 

the  target  has  issued  a  Resource- 
report  indication 

8 

ncctrirecvd 

the  origin  has  issued  a  Reaource- 
control  indication  (response 
required) 

8 

mccirf  sat 

the  target  has  transmitted  a  Re- 
source-control APDU  (response 
required) 

9 

A£Ctrfr©c?d 

the  origin  has  issued  an  Access- 
control  indication 

9 

AccteiEsai 

the  target  has  transmitted  an 
Access-control  APDU 

10 

RJ  ease  Beat 

toe  origin  has  issued  an  A_relea»e 
request 

10 

Mease  ree^d 

die  target  has  issued  an     _rel 
indication. 

11 

Reject 

tfie  target  has  transmitted  an  Init 

Response  APDU  (reject) 
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Table  9a      :  Events  and  action  c 

md  their  Abbreviations  -  Origin 

Incoming  Evert 
Init  request 

Abbreviation 
Init  req 

Outgoing  Action 

Abbreviation 
MtPDU 

InUPDU 

Init-respoiue  PDU 

Knit  rasp  PDU 

Init  confirm 

Init  conf 

Search  request 

Srch  req 

Search  PDU 

Srch  PDU 

Search-response  PDU 

Srch  resp  PDU 

Search  coafirm 

Srch  conf 

Present  request 

Prtotreq 

Present  PDU 

hunt  PDU 

Present-response  PDU 

Prsot  reap  PDU 

Present  confirm 

Print  conf 

Delete  request 

Dltereq 

Delete  PDU 

Dlte  PDU 

Delete-response  PDU 

Dlte  re»p  PDU 

Delete  confirm 

Dheconf 

Resource-report  request 

Rarp  req 

Reaouree-report  PDU 

nrpPDU 

Reiource-report  response  PDU 

Rarp  re«pPDU 

Resource-report  coafirm 

rtrp  conf 

Trigger-resource-control  request 

Trigrc 

Trigger-resource-control  PDU 

trigrc  PDU 

Resource-control  PDU  (response 

Rse  PDU  (Resp) 

Resource-control  indic*tk» 

Rjcbd 

required) 

Resource-control  PDU  (response 

Rao  PDU  (Noretp) 

not  required) 

Resource-control  response 

Rie  reap 

Resource-control-response  PDU 

Rjc  rwpPDU 

Access-control  PDU 

Ace  PDU 

Access-control  indication 

Ace  ind 

Access-control  response 

Ace  resp 

Access-control-response  PDU 

Ace  reap  PDU 

A-Abort  indication 

Aabind 

IR-abort  indication 

bbbd 

A-P-abort  indication 

APabind 

IR-abort  request 

bb  req 

A-abort  request 

Aabreq 

IR-release  request 

Irel  req 

A-release  request 

Arel  req 

A-release  confirm 

Arel  conf 

IR-release  confirm 

Irel  conf 

Save  current  Mate 

akst 

II 

Restore  previously  saved  state 

pop* 

Table  9b:  Events  and  action  and  their  Abbreviations  -  Target 

Incomine  Event 

Abbreviation 

Outgoing.  Action 

Abbreviation 

Init  PDU 

Init  PDU 

Init  indication 

liiitmd 

Init  response 

Init  resp 

Init-responae  PDU 

Init  reap  PDU 

Search  PDU 

Srch  PDU 

Search  indication 

Srchwd 

Search  response 

Srch  resp 

Search-response  PDU 

Srch  reap  PDU 

Present  PDU 

PrsntPDU 

Present  indication 

Print  bd 

Present  response 

Prsnt  resp 

Present-response  PDU 

Print  resp  PDU 

Delete  PDU 

Dlte  PDU 

Delete  indication 

Dlteind 

Delete  response 

Dlte  resp 

Delete-response  PDU 

Dlte  re*p  PDU 

Resource-report  PDU 

RsrpPDU 

Resource-report  indication 

Rarp  ind 

Resource-report  response 

Rarp  resp 

Resource-report-response  PDU 

Rsrp  resp  PDU 

Trigger-resource-control  PDU 

Trigrc  PDU 

Trigger-resource-control  ind 

Trigrc  ind 

Resource-control  Request 

Rac  req  (Resp) 

Resource-control  PDU 

Ric  PDU 

(response  required) 

Resource-control  Request 

Ric  req(Norefp) 

(no  response  required) 

Resouree-control-response  PDU 

Rsc  resp  PDU 

Resource-control  confirm 

R*e  conf 

Access-control  Request 

Ace  req 

Access-control  PDU 

Ace  PDU 

Access-control-response  PDU 

Ace  reap  PDU 

Access-control  confirm 

Ace  conf 

A-abort  indication 

Aabind 

IR-abort  indication 

lab  sad 

A-P-abort  indication 

APabind 

IR-abort  request 

hb  req 

A-abort  request 

Aab  req 

A-release  indication 

Arelind 

IR-release  indication 

Irel  ind 

IR-Release  response 

Irel  resp 

A-release  response 

Arel  reap 

Save  current  itate 

Btfcfit 

Restore  previously  saved  state 

popst 
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Table  10a:  State  Table  for  Origin  -  Pan  1 

State 
Event 

doacd 
1 

2 

Opaa 
3 

Starch  p.mi 
4 

PrE?i  test 
S 

Delete  §«■* 
6 

RwpSent 
7 

Init  req 

Init  PDU  (2) 

InM  reap  PDU 
(ACCEPT) 

Inhconf+  (3) 

Ink  re§p  PDU 
(REJECT) 

Jaitcoiif-; 
Arel  req  (10) 

Srckreq 

Sroh  PDU  (4) 

Srcfc  reap  PDU 

Sroh  conf  (3) 

Prsit  req 

Prmnl  PDU  (5) 

Pmit  reap  PDU 

Prsntconf  (3) 

DUe  req 

Dlte  PDU  (6) 

Dlt«  reap  PDU 

Dlte  conf  (3) 

Rsrp  req 

Rsrp  PDU  (7) 

iRsrp  resp  PDU 

Rsrp  conf  (3) 

iTrigrcreq 

Trigre  PDU 
(2) 

Trigre  PDU 
(4) 

Trigre  PDU 
(5) 

Trigre  PDU 
(6) 

I 

TabU  10b:  Stale  Tabkfor  Origin  - 

Part  2 

__J 

State 
Event 

Init  sent 
2 

Open 

3 

Search 

4 

Pratt  seat 
S 

Delete  seat 

Rsrp  sent 
7 

Rsctri 

swd 

i 

Acctri 

reod 

9 

Rteaseseot 
10 

Rsc  PDU 
1  (Resp) 

Rsc  ind; 
•tie*  (8) 

Rsc  ind; 
stkst(8) 

Rsc  ind; 
«krt(8) 

Rsc  ind; 
«tkst(8) 

Rsc  PDU 
(Noresp) 

Rsc  ind 
(2) 

R»eind 
(4) 

Rsc  ind 
(5) 

Rsc  ind 
(6) 

HRsc  resp 

Rsc  resp 
PDU;  poprt 

Ace  PDU 

Ace  ind; 
stk*(9) 

Ace  ind; 
«k*t(9) 

Ace  ind; 
«k*(9) 

Ace  ind; 
■tk»t(9) 

Ace  ind; 
«kst(9) 

Ace  resp 

Ace  resp 
PDU;  popst 

Aabkkd 

lab  ind  (1) 

I»b  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

Apah  ind 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

lab  ind  (1) 

kb  ind  (1) 

hb  ind  (1) 

lab  ind  (1) 

lab  req 

Aab  req 
(1) 

Aab  req 
(1) 

Aab  req 
(1) 

Aab  req 
(1) 

Aab  req 
(1) 

Aab  req 
0) 

Aab  req 
(1) 

Aab  req 
(1) 

Aab  req 
(1) 

Irei  req 

Arel  req  (10) 

Arel  conf 

Irelconf(l) 
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Table  11a:  State  Table  for  Target  -  Part  1 

State 
Event 

Ck»ed 
1 

hitncTd 

2 

Ope* 
3 

Search  R£V<1 
4 

5 

Delete  reevd 

InitPDU 

Initial  (2) 

Mraip 
(ACCEPT) 

Initreip 
PDU(-f)  (3) 

Ink  rap 
(REJECT) 

bit  rwp 
PDU(-)(11) 

SrehPDU 

Sreh  tod  (4) 

Srchresp 

Srch  resp  PDU  (3) 

Pratt  PDU 

Pr«raiiad(5) 

Print  resp 

Pi-wit  rerp  PDU  (3) 

DltePDU 

Dlt*  tod  (6) 

Dtteresp 

Dlte  resp  PDU  (3) 

Table  lib:  State  table  for  Target  -  Part  2 

State 
Event 

Ink 

recvd 

2 

Open 

3 

Search 

recvd 

4 

Print 
recvd 

S 

Delete 

r@cvd 

6 

Rsrp 

recvd 

1 

Ractri 

i 

Acctri 
9 

RJease 

ir@cvd 

10 

Reject 
11 

Rsrp 
PDU 

Rsrp 
lndC7) 

Rsrp 
resp 

.' 

PDU  (3) 

Trigre 
PDU 

Trigre 
ind(2) 

ignore 
(3) 

Trigre 
tod  (4) 

Trigre 
tod  (5) 

Trigre 
tod  (6) 

ignore 
(8) 

ignore 
(9) 

ignore 
(11) 

Rsc  req 
(Resp) 

Rsc 

PDU; 

Kkxt  (8) 

Rsc 

PDU; 

stkst(8) 

Rsc 

PDU; 

stkst(8) 

Rsc 

PDU; 

Mkst(8) 

Rsc  req 

1   (Noresp) 

Rsc  PDU 
(2) 

RsePDU 
(4) 

Rsc 
PDU  (5) 

Rsc  PDU 
(6) 

Rsc  reap 
PDU 

Rsc 
conf; 
pop  »t 

Ace  req 

Ace 

PDU; 

ftkst(9) 

Ace 

PDU; 

Skirt  (9) 

Ace 

PDU; 

*Ucst(9) 

Ace 
PDU; 

«kst(9) 

Ace 

PDU; 

•Oast  (9) 

Ace  resp 
PDU 

Ace 
conf; 
pop* 

• 

Arelmd 

WW 
(10) 

Irel 
tod 
(10) 

Irel  rap 

Arel 
«sp(l) 

Aabind 

lab 
ind(l) 

hb 
ind(I) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

Apab 
fed 

hb 
iod(l) 

hb 
ind(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

hb 
tod(l) 

lab  req 

Aab 
wqd) 

Aab 
reqd) 

A»b 
reqd) 

Aab 
nq(l) 

Aab 
req(l) 

A»b 
«*1  (1) 

A»b 
req(l) 

Aab 
req(l) 

Aab 
nq<l) 

Mb 
req(l) 
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4.4  Conformance 

A  system  claiming  to  implement  the  procedures  in 
this  standard  shall  comply  with  the  requirements  in 
sections  4.4.1,  4.4.2,  and  4.4.3. 

4.4.1  Statk  Requirements 

The  system  shall: 

a)  act  in  the  role  of  an  origin  (by  sending  Init, 
Search,  and  Present  APDUs  and  receiving 
Init-response,  Search-response  and  Present- 
response  APDUs),  or  target  (by  responding 
properly  to  Init,  Search,  and  Present  APDUs 
with  appropriate  Init-response,  Search-re- 
sponse and  Present-response  APDUs),  or 
both;  and, 

'     b)    support  the  syntax  in  section  4.1,  and 
c)    support  the  Type-1  Query. 

4.4 J2  Dynamic  Requirements 

The  system  shall  exhibit  external  behavior  consis- 
tent with  having  implemented: 

a)  an  Information  Retrieval  ASE  which  follows 
all  the  procedures  specified  in  sections  4.1.1, 
4.2,  and  4.3; 

b)  the  mapping  onto  the  Association  Control  ' 
Service  and  Presentation  Service  (see  4.2.1); 

c)  assignment  of  values  to  APDU  data  elements 
according  to  the  procedures  described  in 
section  3; 

d)  encoding  of  APDUs  by  applying  the  ASN.l 
Basic  Encoding  Rules  (ISO  8825)  to  the 
abstract  syntax  defined  in  section  4.1.1;  and 

e)  the  Type-1  query  whose  abstract  syntax  is 
defined  in  section  4.1.1  and  whose  structure 
and  rules  for  evaluation  are  described  in 
section  3.2.2.1.1.1. 

4.43  Statement  Requirements 

Each  implementation  must  provide  a  Protocol 
Implementation  Conformance  Statement  (PICS). 

1.  The  following  shall  be  stated  by  the  PICS: 

a)  whether  the  system  is  capable  of  acting  in  the 
role  of  origin, 

b)  whether  the  system  is  capable  of  acting  in  the 
role  of  target, 

c)  that  the  system  supports  versions  1  and  2  of 
the  Z39.50-1992  protocol. 

2.  If  the  system  claims  the  capability  of  acting  in  the 
role  of  origin  the  PICS  shall  state  whether  the  sys- 
tem: 

a)  accepts  Access-control  APDUs  and  sends 
Access-control-response  APDUs, 


b)  accepts  Resource-control  APDUs  and  sends 
Resource-control-response  APDUs, 

c)  sends  Resource-report  APDUs  and  accepts 
Resource-report  response  APDUs, 

d)  sends  Trigger-resource-control  APDUs, 

e)  sends  Delete  APDUs  and  accepts  Delete- 
response  APDUs, 

f)  sends  Search  and  Present  APDUs  specifying 
named  result  sets  other  fcan  "default*. 

3.  If  the  system  claims  the  capability  of  acting  in  me 
role  of  target,  the  PICS  shall  state  whether  the 
system: 

a)  sends  Access-control  APDUs  ttid  accepts 
Access-control-respons©  APDUs, 

b)  sends  Resource-control  APDUs  and  accepts 
Resource-control-response  APDUs, 

c)  accepts  Resource-report  APDUs  and  sends 
Resource-report  response  APDUs, 

d)  accepts  Trigger-resource-control  APDUs, 

e)  accepts  Delete  APDUs  and  sends  Delete- 
response  APDUs, 

f)  accepts  Search  and  Present  APDUs  specifying 
named  result  sets  other  than  "default0, 

g)  unilaterally  deletes  result  sets. 

4.  The  PICS  shall  state  to  what  extent  result  sets  may 
be  specified  as  operands  in  a  Type-1  query: 

a)  whether  named  result  sets  in  general,  or  only 
the  default  result  set,  may  be  used  as  an 
operand  in  a  Type-1  query, 

b)  whether  result  sets  may  be  specified  only  as 
the  first  operand  in  a  Type-1  query,  or  may 
be  specified  as  any  operand, 

c)  with  which  operators  (AND,  OR,  AND-NOT) 
result  sets  may  be  used  as  operands. 

5.  The  PICS  shall  state  to  what  extent  element  set 
names  are  supported  in  Search  and  Present  APDUs: 

a)  whether  the  parameter  Element-set-names  is 
supported, 

b)  if  the  parameter  Element-set-names  is  support- 
ed, whether  database  names  corresponding' to 
element  set  names  may  be  specified,  or  only 
a  single  element  set  name  and  no  correspond- 
ing database  name  may  be  specified. 

6.  The  PICS  shall  state: 

a)  for  each  optional  parameter  in  each  APDU, 
whether  or  not  the  parameter  is  supported; 

b)  which  encoding  rules  are  supported; 

c)  the  maximum  number  of  database  Dames 
which  may  be  specified  in  a  Search  APDU; 

d)  which  attribute  sets  are  supported. 

Note:  A  PICS  proforma  will  be  standardized  in  the 
future. 
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APPENDIX  A:  Object  Identifiers  Assigned  in  This  Standard 


This  appendix  is  part  of  the  standard. 

The  following  object  identifier  value  has  been 
assigned  to  this  standard,  ANSI-standard-Z39.50: 

{  iso  (1)  member-body  (2)  US  (840) 
ANSI-standard-Z39.S0  (10003)} 

This  standard  assigns  the  following  values  at  the 
level  immediately  subordinate  to  ANSI-standard- 
Z39.50: 

1  «=  application  context 

2  =  abstract  syntax 
.    3  =  attribute  set 

4  =  diagnostic  set 

5  =  abstract  record  syntax 

6  =  transfer  syntax  for  non-bibliographic  records 

7  =  resource  report  format 

A.l  Application  Context 

This  standard  assigns  the  following  object  identifi- 
er for  the  application-context-definition 
'basic-Z39.50-ac\  contained  in  Appendix  B: 

{  iso  member-body  US  ANSI-standard-Z39.S0 
application-context  (1)  basic-Z39.iO-ac  (1)  } 

A  J2  Abstract  Syntax 

This  standard  assigns  the  following  object  identifi- 
er for  the  ASN.l  module,  contained  in  section  4.1, 
defining  the  Z39.50  APDUs: 

{  iso  member-body  US  ANSI-standard-Z39.50 
abstract-syntax  (2)  Z39.IO-apdus  (1)  > 

Note:  No  object  identifier  is  assigned  by  this 
standard  for  any  transfer  syntax  for  .apdus.  The 
transfer  syntax  results  from  the  application  of  the 
ASN.l  Basic  Encoding  Rules  (ISO  8825).  For  the 


purposes  of  Presentation  Context  negotiation,  this 
syntax  is  identified  by  a  pair  of  object  identifiers,  one 
for  the  abstract-syntax  (Z39.5G-apdus)  and  one  for 
the  basic  encoding  rules: 

{  joint-iso-cdtt  ssnl  (1)  bask-mcoding  (1)  } 

A3  Attribute  set 

This  standard  assigns  the  following  object  identifi- 
er for  the  attribute-set  definition  'bib-l',  contained  in 
Appendix  C: 

{  iso  member-body  US  ANSI-standard-Z39.IO 
attribute-set  (3)  bib-l  (1)  > 

A.4  Diagnostic  Set 

This  standard  assigns  the  following  object  identifi- 
er for  the  diagnostic  set  definition  contained  in  appen- 
dix D. 

{  iso  member-body  US  ANSI-standard-Z39.50 
diagnostic-set  (4)  bib-l  (1)} 

AS  Abstract  Record  Syntax 

Object  identifier  for  Record  syntaxes  are  contained 
in  appendix  E. 

A.6  Transfer  Syntax  for  Non-bMo- 
graphk  Records 

No  transfer  syntaxes  for  non-bibliographic  records 
are  designated  within  this  standard. 

A.7  Resource  Report  Fonnat 

This  standard  assigns  the  following  object  identifi- 
er for  the  resource  report  format  defined  in  appendix 
F. 

{  iso  member-body  US  ANSI-standard-Z39.50 
resource-report-format  (7)  bib-l  (1)} 


APPENDIX  B:  Definition  of  Application  Context  basfc-Z39«50-«c 


This  appendix  is  part  of  the  standard. 

This  appendix  defines  the  application  context 
basic-Z39.50-ac.  The  object  identifier  for  application 
context  basic-Z39.50-ac  is  registered  in  Appendix  A. 

Definition  of  application  context  basic-Z39.50-ac 
ANSI-standard-Z39.50   application   context   basic- 
Z39.50-ac,  supports  an  application-entity  that  contains 
only  the  following  two  application  service  elements 
(ASEs): 


a)  the    association    control    service    element 
(ACSE,  ISO  8650),  and 

b)  the  Z39.50  service  element. 

Z39.50  and  ACSE  are  used  according  to  the 
procedures  in  section  4.2.1. 

The  P-Data  service  is  used  to  transmit  Z39.50 
APDUs. 

In  the  event  of  protocol  errors,  the  system  detect- 
ing the  error  shall  abort  the  association. 
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APPENDIX  C:  Attribute  Set  MM. 


This  appendix  is  part  of  the  standard. 

This  Appendix  defines  the  attribute-set  bib-1. 
Attribute-set  bib-1  is  primarily  intended  for  use  with 
bibliographic  databases.  The  object  identifier  for 
attribute  set  bib-1  is  defined  and  registered  in  Appen- 
dix A.  When  the  value  of  AttributeSetld  (within  the 


RPNDefinitioa  within  the  Search  APDU)  equals  flie 
object  identifier  for  this  attribute-set,  then: 

a)  AttributeType  (within  AttributeElernent  within 
AttributeList)  takes  values  from  table  C-l 
below,  and 

Attribute  Value  takes  values  from  the  corre- 
sponding attribute  table  (C2  through  C7). 


b) 


Table  C-l:  Attribute 

Types 

Attribute  Type 

Value 

Ute 

1 

Relation 

2 

Position 

3 

Structure 

4 

Truncation 

5 

Completeness 

6 

U2£ 

Personal  name 

Corporate  name 

Conference  name 

Title 

Title  series 

Title  uniform 

ISBN 

ISSN 

IX  card  number 

BNB  card  number 

BGF  number 

Local  number 

Dewey  classification 

UDC  classification 

Bliss  classification 

LC  call  number 

NLM  call  number 

NAL  call  number 

MOS  call  number 

Local  classification 

Subject  heading 

Subject  Rameau 

BDI  index  subject 

INSPEC  subject 

MESH  subject 

PA  subject 

LC  subject  heading 

RVM  subject  heading 

Local  subject  index 

Date 


Table  C-Z-  Use  Attributes 

Value 

Use 

Value 

yjs 

Value 

1 

Date  of  publication 

31 

Microform  generation 

61 

2 

Date  of  acquisition 

32 

Abstract 

62 

3 

Title  key 

33 

Note 

63 

4 

Title  collective 

34 

Author-title 

1000 

5 

Title  parallel 

35 

Record  type 

1001 

6 

Title  cover 

36 

Name 

1002 

7 

Title  added  title  page 

37 

Author 

1003 

8 

Title  caption 

38 

Author-name  personal 

1004 

9 

Title  running 

39 

Author-name  corporation 

1005 

10 

Title  spine 

40 

Author-name  conference 

1006 

■      11 

Title  other  variant 

41 

Identifier  -  standard 

1007 

■      12 

Title  former 

42 

Subject  -  LC  children's 

1008 

13 

Title  abbreviated 

43 

Subject  name  -  personal 

1009 

14 

Title  expanded 

44 

Body  of  tat 

1010 

i      15 

Subject  precis 

45 

DateAime  added  to  database 

1011 

r      16 

Subject  rswk 

46 

DateAime  last  modified 

1012 

r     17 

Subject  subdivision 

47 

Authority  and  format  identifier 

1013' 

r     18 

Number  natl  bibliography 

48 

Concept-text 

1014 

r      19 

Number  legal  deposit 

49 

Concept-reference 

1015 

l      20 

Number  govt  publication 

50 

21  Number  publisher  for  music  51 

22  Number  db  52 

23  Number  local  call  53 

24  Code  -  language  54 

25  Code  -  geographic  area  55 

26  Code  -  institution  56 

27  Name  and  title  57 

28  Name  geographic  58 

29  Place  publication  59 

30  CODEN  60 


35 


Table  C-3:  Relation  Attributes 

Relation 

Value 

lets  thin 

1 

ktt  than  or  equal 

2 

equal 

3 

greater  or  equal 

4 

greater  than 

5 

not  equal 

6 

Note:  "term"  U  the  right  operand  of  the 
relation.  For  example,  if  'Use'  is  'date', 
'relation'  is  'less  than',  and  'term'  is  1800', 
then  the  relationship  is  "date  less  than  1800" 

Table  C-4:  Position  Attributes 

Position 

Value 

firei  in  field 

1 

firal  in  Eubfteld 

2 

any  position  in  field 

3 

Table  C-5:  Structure  Attributes 

Structure 

Value 

Phrase 

1 

word 

2 

key 

3 

year 

4 

date  (normalized) 

5 

word  list 

6 

date  (un-normahzed) 

100 

name  (normalized) 

101 

name  (un-normahzed) 

102 

Tabk  C-&  Truncation  Attributes 

Truncation 

Value 

Right  Truncation 

1 

Left  truncation 

2 

Left  and  right 

3 

Do  not  truncate 

100 

Process  #  in  the  search  term 

1 - 

101 

Table  C-7:  Completeness  Attributes 

Completeness 

Value 

incomplete  subfield 

1 

complete  tubfield 

2 

complete  field 

3 
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APPENDIX  D:  Diagnostic  Set  bib-1 


This  appendix  is  part  of  the  standard. 

This  Appendix  defines  the  diagnostic  set  bib-1. 
The  object  identifier  for  diagnostic  set  bib-1  is 
defined  and  registered  in  Appendix  A. 


When  the  value  of  DiagnosticSetld  (within  Diag- 
Rec  within  the  auxiliary  definitions  for  Search  Re- 
sponse and  Present  Response  APDUs)  equals  the 
object  identifier  for  this  diagnostic  set,  then  "condi- 
tion" (within  DiagRec)  takes  values  from  the  "Condi- 
tion'1 column  in  the  table  below. 


Table  D-l:  Dia&iossk  CondMom 


Condition  Meanint 

1  Permanent  system  error 

2  Temporary  system  error 

3  Unsupported  search 

4  Terms  only  exclusion  (stop)  words 

5  Too  many  argument  words 

6  Too  many  boolean  operators 

7  Too  many  truncated  words 

8  Too  many  incomplete  subfields 

9  Truncated  words  too  short 

10  Invalid  format  for  record  number  (search  term) 

11  Too  many  characters  in  search  statement 

12  Too  many  records  retrieved 

13  Present  request  outof-range 

14  System  error  in  presenting  records 

15  Record  not  authorized  to  be  »ent  intersystem 

16  Record  exceeds  Preferred-message-size 

17  Record  exceeds  Maximum-record-size 

18  Result  set  not  supported  as  a  search  term 

19  Only  single  result  set  as  search  trm  supported 

20  Only  ANDing  of  a  single  result  set  as  search  term  supported 

21  Result  set  exists  and  replace  indicator  off 

22  Result  set  naming  not  supported 

23  Combination  of  specified  databases  not  supported 

24  Element  set  names  not  supported 

25  Specified  element  set  name  not  valid  for  specified  database 

26  Only  a  single  element  set  name  supported 

27  Result  set  no  longer  odsU  -  unilateraUy  deleted  by  target 

28  Result  set  is  in  use 

29  One  of  the  specified  databases  to  locked 

30  Specified  result  set  does  not  exist 

31  Resources  exhausted  -  no  results  available 

32  Resources  exhausted  -  unpredictable  partial  result*  available 

33  Resources  exhausted  -  valid  subset  of  results  available 


Addinfo 


Tyus 

1 
1 

2 
2 
2 
2 
2 
2 
2 
2 
2 
2 
3 
4 
4 
4 
4 
2 
2 
2 
2 
2 
2 
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Condition      Meaning 


Addinfo 


Jm. 


100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
111 
112 
113 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 


Unspecified  error 

Access-control  failure 

Security  challenge  required  but  could  not  be 

Security  challenge  required  but  could  not  be 

Security  challenge  failed  -  record  not  included 

Terminated  by  negative  continue  response  ' 

No  abstract  syntaxes  agreed  to  for  this  record 

Query  type  not  supported 

Malformed  query 

Database  unavailable 

Operator  unsupported 

Too  many  databases  specified 

Too  many  result  sets  created 

Unsupported  attribute  type 

Unsupported  Use  attribute 

Unsupported  value  for  Use  attribute 

Use  attribute  required  but  not  supported 

Unsupported  Relation  attribute 

Unsupported  Structure  attribute 

Unsupported  Position  attribute  , 

Unsupported  Truncation  attribute 

Unsupported  Attribute  Set 

Unsupported  Completeness  attribute 

Unsupported  attribute  combination 

Unsupported  coded  value  for  term 

Malformed  search  term 

Illegal  term  value  for  attribute 

Unparsable  format  for  un-normalized  value 

Illegal  result  set  name 

Proximity  search  of  sets  not  supported 

Illegal  result  set  in  proximity  search 

Unsupported  proximity  relation 

Unsupported  proximity  unit  code 


•  request  terminated 
^record  not  included 


Notes  for  table  D-l 

1.  "Type"  is  as  follows: 

(1)  May  occur  when  search-status  or  present-status  = 
"failure". 

(2)  May  occur  only  when  search-status  =  "failure''. 

(3)  May  occur  only  when  present-status  =  "failure''. 

(4)  May  occur  only  as  a  surrogate  for  a  database 
record. 

2.  Where  an  entry  occurs  in  the  "addinfo"  column 
for  a  given  condition,  it  refers  to  information 


1 

1 

1 

4 

4 

1 

4 

2 

2 

database  name 

2 

operator 

2 

Es&xmmiEi 

2 

EQUXUHUin 

2 

type 

2 

value 

2 

term 

2 

2 

value 

2 

value 

2 

value 

2 

value 

2 

oid 

2 

value 

2 

2 

value 

2 

2 

term 

2 

value 

2 

name 

1 

2 

result  set  name 

2 

value 

2 

value 

2 

associated  with  that  condition;  for  example,  for 
condition  114  "Unsupported  Use  attribute'',  Add- 
info specifies  "value",  referring  to  the  value  of  the 
Use  attribute  which  is  not  supported.  These  entries 
in  the  Addinfo  column  are  recommended  to  be 
included  within  DiagRec  within  the  auxiliary 
definitions  for  Search  Response  and  Present 
Response  APDUs. 
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APPENDIX  E:  Record  Syntaxes 


This  appendix  is  part  of  the  standard. 

This  appendix  defines  and  registers  object  identifi- 
ers for  abstract  record  syntaxes.  These  identifiers  are 
intended  to  be  used  as  the  values  of  PreferredRecord- 
Syntax  in  Search  and  Present  APDUs. 

E.1  Abstract  Record  Syntaxes 

E.1.1  Abstract  Record  Syntaxes 

Registered  by  this  Standard 

Names  are  assigned  using  the  ASN.l  notation 
■  (ISO  8824)  for  OBJECT  IDENTIFIER  values: 

ANSI-Z39-50-2  DEFINITIONS  ::  = 

BEGIN 

Z39-50  OBJECT  IDENTIFIER  ::  = 

{  iso  (1)  member-body  (2)  US  (840) 

ANSI-standard-Z39.50  (10003)} 
RecordSyntax  OBJECT  IDENTIFIER  ::  = 

{  Z39-50  (5)  } 


Ummarc 

:i-  OBJECT  IDENTIFIER  (RoradSyimix  (1)} 

Intermarc 

::-  OBJECT  IDENTIFIER  (RMoriSyBUx  (2)} 

CCF 

::-  OBJECT  IDENTIFIER  (RocariSyBtM  (3)} 

USmarc 

::-  OBJECT  IDENTIFIER  (RecordSyBiM  (10)} 

UKmarc 

::-  OBJECT  IDENTIFIER  (RecoriSynaa  (11)} 

Normarc 

::-  OBJECT  IDENTIFIER  (RtwKdSyiSM  (12)} 

Librismarc 

::-  OBJECT  IDENTIFIER  (RsowdSyraaj  (13)} 

Danmarc 

■.:-  OBJECT  IDENTIFIER  {foasdSyrtM  (14)} 

Finmarc 

::-  OBJECT  IDENTIFIER  {ReooKByaK  (If)} 

MAB 

::-  OBJECT  IDENTIFIER  {ReeoriSyotia  (16)} 

Canmarc 

::-  OBJECT  IDENTIFIER  (RueoriSyum  (17)} 

SBN 

::-  OBJECT  IDENTIFIER  {RocardSynUa  (18)} 

Picamarc 

::-  OBJECT  IDENTIFIER  (RMorfSyMax  (19)} 

END 

E.O  Local  Abstract  Record  Syntaxes 

For  registration  of  local  abstract  record  syntaxes, 
this  appendix  defines  and  registers  flie  following 
object  identifier: 


LocalSyntax  ::=  OBJECT  IDENTIFIER 
{  RecordSyntax  (1000)} 

Local  abstract  record  syntaxes  will  be  registered 
subordinate  to  this  object  identifier.  Contact  the 
Z39.50  Maintenance  Agency  for  registration  proce- 
dures. 

K2  Transfer  Syntax  for  Records 

For  the  purposes  of  Presentation  Context  negotia- 
tion, record  syntax  is  identified  by  a  pair  of  object 
identifiers,  one  for  the  abstract-syntax  and  one  for  the 
transfer  syntax. 

For  bibliographic  records,  no  object  identifiers  for 
transfer  syntax  are  assigned  by  this  standard.  How- 
ever, an  object  identifier  has  been  assigned  (outside 
of  this  standard)  for  the  transfer-syntax  for  biblio- 
graphic records  defined  in  ISO  2709: 

{iso  standard  2709  transfer-syntax   (1) 
character-encoding  (1)} 

For  non-bibliographic  records,  transfer  syntaxes 
will  be  registered  subordinate  to  ttie  object  identifier 
{Z39-50  7}  (see  Appendix  A). 
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APPENDIX  F:  Resource  Report  Format  bib-1 

This  appendix  is  part  of  the  standard. 

This  Appendix  defines  the  resource  report  format  bib-1.  The  object  identifier  for  resource  report  format  bib-1 
is  defined  and  registered  in  Appendix  A. 

ResourceReportFormat-Bib-1 

{  iso  member-body  US  ANSI-standard-Z39.50  reouiw-report-format  (7)  bib-1  (1)}  ;:= 

BEGIN 

ResourceReport  :;=  SEQUENCE{ 

estimates  [1]  IMPLICIT  SEQUENCE  OF  Estimate, 

message  [2]  IMPLICIT  VisibleString} 

Estimate  ::=  SEQUENCE{ 

type  [1]  EstimateType, 

value  [2]  IMPLICIT  INTEGER,  -  the  actual  estimate 

currency-code        [3]  IMPLICIT  INTEGER  OPTIONAL} 

--  code  for  representation   of  currencies  defined  in  ISO  4217-1990. 

~  Applicable  only  to  monetary  estimates 


estimated  number  of  records  in  current  (incomplete) 

result  set  for  search 

estimated  number  of  records  that  wUl  be  in  the  result 

set  for  search  if  the  search  completes 

estimated  number  of  records  in  current  (incomplete)  m  of 

records  to  be  returned  on  Present 

estimated  number  of  records  that  wUl  be  in  the  $et  of  records 

to  be  returned  by  Present  if  Present  completes 

processing  time  (in  .001  CPU  seconds)  used  by 

this  operation  so  fin' 

estimated  total  processing  time  (in  .001  CPU  teconds)  that  wUl 

be  used  by  Ms  operation  if  it  completes 

estimated  processing  time  used  by  Ms  association 

(in  .001  CPU  seconds) 

estimated  cost  for  Ms  operation  so  far 

estimated  cost  for  Ms  operation  if  it  completes 

estimated  cost  for  Ms  association  so  far 

estimated  elapsed  time  for  Ms  operation  if  it  completes 

(in  .001  second  units) 


EstimateType  ::=  IMPLICIT  INTEGER{ 
currentSearchRecords            (1), 

finalSearchRecords 

(2),       - 

currentPresentRecords 

(3),       - 

finalPresentRecords 

(4),      - 

currentOpTimeProcessmg 

(5),      - 

finalOpTimeProcessing 

(6),       - 

currentAssocTime 

(7),       - 

currentOperationCost 
flnalOperationCost 
currentAssocCost 
BnalOpTimeElapsed 

(8),      - 
(9),      - 
(10),     - 

(11)},  - 

END 
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APPENDIX  Gj   Proximity  Query 

This  appendix  is  part  of  the  standard. 

This  Appendix  defines  the  Proximity  query,  Type- 
101. 

G.l  Structure  of  the  Proximity  Query  The  Prox- 
imity query  is  an  extension  of  the  RPN-Query.  It  is 
identical  in  structure  with  the  exception  that  a  prox- 
imity operator  is  represented  in  addition  to  the  exist- 
ing RPN-Query  operators  AND,  OR,  AND-NOT. 
Thus  the  Proximity  query  is  defined  as  follows: 

Proximity-query  ::- argument  | 

argument  +  argument  +  operator 
argument  :;=   operand  |  Proximity-query 
operand     ::=    attribute-set  +  term  | 

Result-set-id 
operator    ::=   AND  |  OR  |  AND-NOT  |  PROX 

Where  the  notation  is  as  described  in  section 
3.2.2.1.1.1. 

G.2  Representation  and  Evaluation  At  the  origin, 
the  Type-101  query  is  represented  by  a  tree.  Each' 
leaf  node  contains  a  simple  operand  and  each  non-leaf 
node  contains  a  complex  operand.  A  simple  operand 
is  either  a  Result-set-id  or  an  Attribute-set + Term.  A 
complex  operand  is  a  subtree  whose  root  is  an  oper- 
ator and  which  contains  two  subtrees:  a  left-hand 
operand  and  a  right-hand  operand,  LO  and  RO.  A 
complex  operand  is  thus  one  of  the  following: 

-  LO  AND  RO,  representing  the  intersection  of 
LO  and  RO; 

-  LO  OR  RO,  representing  the  union  of  LO  and 
RO; 

-  LO  AND-NOT  RO,  representing  the  set  of 
elements  in  LO  that  are  not  in  RO;  or 

-  LO  PROX  RO,  representing  the  set  of  ele- 
ments resulting  from  the  application  of  the 
PROX  operator  to  the  operands  LO  and  RO, 
as  described  in  G.3. 

At  the  target,  evaluation  of  the  tree  is  illustrated 
by  the  use  of  a  stack.  The  tree  is  processed  according 
to  a  left  post-order  traversal.  Each  leaf-node  is  one 
of  the  following: 

a)  Attribute-set  +  Term 

b)  Result-set-id 

c)  Operator 

Whenever  (a)  or  (b)  is  encountered,  it  is  put  on 
the  stack. 

Whenever  (c)  is  encountered: 

-  Let  A  and  B  refer  to  the  last  two  items  put  on 
the  stack  in  the  order  mat  they  were  put  on 


fiie  stack.  A  and  B  are  pulled  off  and  the 
operator  is  applied  as  follows: 
o  If  the  operator  is  AND,  OR,  or  AND- 
NOT:  if  A  is  of  the  form  ■Attribute  Set 
+  Term0,  then  A  is  evaluated  against  the 
collection  of  databases  specified  k  the 
Search  request,  and  the  result  is  A';  oth- 
erwise A*  =  A.  Likewise  if  B  is  of  the 
form  "Attribute  Set  +  Term0,  then  B  is 
evaluated  against  the  collection  of  databas- 
es specified  in  the  Search  request,  and  the 
result  is  B';  otherwise  B'=  B. 

Note:  in  all  cases,  A'  and  B'  are  sets. 
Each  is  either  a  result  set  or  an  inter- 
mediate set  resulting  from  a  previous 
operation. 

-  if  operator  is  AND,  the  result  is  the 
intersection  of  A'  and  B'; 

-  if  operator  is  OR,  the  result  is  the 
union  of  A'  and  B'; 

-  if  operator  is  AND-NOT,  the  result  is 
the  set  of  elements  in  A'  which  are 
not  in  B'. 

o     If  the  operator  is  PROX: 

-  if  both  A  and  B  are  of  the  form  "At- 
tribute Set  +  Term0  the  result  is  the 
subset  of  elements  in  the  collection  of 
databases  specified  in  the  Search  re- 
quest, for  which  A  PROX  B  is  true 
(see  G.3). 

-  If  either  A  or  B  is  not  of  the  form 
"Attribute  Set  +  Term"  (i.e.  if  A  or 
B  is  a  set)  then  this  standard  does  not 
specify  the  result  (see  note  below). 

Note:  The  use  of  the  proximity 
operator  when  one  or  both  oper- 
ands is  a  set  is  for  further  study. 
A  query  that  attempts  to  use  the 
proximity  operator  in  this  manner 
is  not  considered  to  be  in  error. 
A  target  that  supports  the  type- 
101  query  may  support  or  not 
support  this  use  of  the  proximity 
operator.  If  so,  the  target  must 
also  specify  the  meaning  of  the 
result.  If  not,  upon  receipt  of 
such  a  query,  the  target  may 
return  a  diagnostic  such  as  "Prox- 
imity search  of  sets  not  support- 
ed'' (see  appendix  D). 
The  resulting  set  is  then  put  on  the  stack. 
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When  evaluation  of  the  query  is  complete  (i.e.  ill 
query-terms  have  been  processed)  there  will  be  one 
item  remaining  on  the  stack  (otherwise  the  query  is  in 
error)  which  is-  the  result  of  the  query. 

G 3  Proximity  Operator  The  proximity  operator, 
PROX,  includes  a  Distance,  Relation-type,  Proximi- 
ty-unit-code, and  two  boolean  flags:  Exclusion  and 
Ordered. 

Example:   suppose  A  and  B  respectively  specify 
"personal  name  =  'McGraw,  J.'  "  and  "personal 
name  =  'Stengel,  C  ",  and: 
Distance  is  0, 

-  Relation-type  is  "equal",  and 

-  Proximity-unit  is  "paragraph". 

Then  the  result  is  the  set  of  record  in  which  both 
of  the  personal  names  occur  within  the  same  para- 
graph. 

Using  the  same  example,  if  the  Exclusion  flag  is 
set  to  "true",  the  result  is  the  set  of  record  in  which 
the  two  personal  names  never  both  occur  within  the 
same  paragraph. 

If  the  Ordered  flag  is  set  to  "true"  (and  Exclusion 
flag  to  "false")  then  the  result  is  the  set  of  record  in 
which  the  personal  name  'McGraw,  J.'  occurs  within 
the  same  paragraph  as,  but  before,  the  personal  name 
'Stengel,  C.\ 

If  distance  is  instead  1  ("ordered"  and  "exclusion" 
flag  "false")  the  result  is  the  set  of  records  in  which 
the  two  persona]  names  occur  in  adjacent  paragraphs. 
If,  in  addition,  Relation-type  is  "less-than-or-equal" 
the  result  is  the  set  of  records  in  which  the  two 
names  occur  within  the  same  or  adjacent  paragraphs. 

G.4  ASN.l  Description  of  Proximity  Query   The 

proximity  query  is  an  extension  of  the  RPN  query 
and  has  the  same  structure  with  the  addition  of  a 
proximity  operator.  Thus  the  proximity  query  is 
described  by  replacing  (within  the  description  of 
RPN-Query  in  section  4.1.1): 


Operator  ::=  [46]    CHOICE{ 

■nd  [0]  IMPLICIT  NULL, 

or  [1]  IMPLICIT  NULL, 

«nd-not  [2]  IMPLICIT  NULL, 

prox  [3]  IMPLICIT  ProximityOperator} 

ProximityOperatof  ::=  SEQUENCE{ 

exclusion  [1]  IMPLICIT  BOOLEAN 

OPTIONAL, 

—  °true°  means  that  °mot°  it  to  be  applied 

—  to  the  proximity  operation.   7he  default 

—  is  "false', 

distance  [2]  IMPLICIT  INTEGER, 

—  Number  ofunlu  between  the  operands  plus 

—  one;  i.e.  the  difference  between  the 

—  ordinal  positional  values  of  the  two 

—  operands.  Distance  Is  never  negative. 
ordered  [3]  IMPLICIT  BOOLEAN, 

—  True '  means  "right  proximity  only '; 

—  'false  '  means  'right  or  left ". 
relationType      [4]  IMPLICIT  INTEGER{ 


Operator   : 
and 
or 
and-not 


[46]    CHOICE{ 
[0]  IMPLICIT  NULL, 
[1]  IMPLICIT  NULL, 
[2]  IMPLICIT  NULL} 


lessThan 

(1), 

lessThauOrEqual 

(2), 

equal 

(3), 

greaterThanOrEqual 

(4), 

greaterThan 

(5), 

notEqual 

(6)}, 

proximityUnitCode  [5]  CHOICE{ 

known 

[1]  IMPLICIT 

KnownProximityUnit 

private 

[2]  IMPLICIT 

INTEGER} 

>wnProximityUnit : 

:=  INTEGER{ 

character 

(D» 

word 

(2), 

sentence 

(3), 

paragraph 

(4), 

section 

(5), 

chapter 

(6). 

document 

(7), 

field 

(8), 

• 

subfield 

(9), 

fieldtype 

(10)} 

-< 

Other  codes  may  be  added. 

With  the  following: 
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